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Abstract 


In  this  report,  we  investigate  the  feasibility  of  a  tabular  interface  for  the  specifi¬ 
cation  and  analysis  of  event-based  dialogues.  These  dialogues  are  used  to  define 
high-level  descriptions  of  interactive  systems,  and  they  are  based  on  Olsen's 
Propositional  Production  System  (PPS)  notation.  The  simulation  of  the  abstract 
user-system  dialogue  is  an  effective  means  of  matching  a  design  with  an 
expected  task  model.  Monk  and  Curry  have  produced  a  prototype  dialogue  simu¬ 
lation  tool,  the  Action  Simulator,  which  demonstrates  how  a  tubular  paradigm 
can  be  used  to  specify  and  simulate  the  dialogue.  Further  analysis  of  the  dialogue 
can  uncover  problems  which  are  not  so  easy  to  detect  with  simulation,  if  we 
view  the  dialogue  as  defining  a  finite  state  machine,  then  we  can  make  use  of 
powerful  model  verification  tools,  such  as  Clarke's  Symbolic  Model  Verifier 
(SMV)  tool,  to  perform  more  powerful  analyses  on  the  dialogue.  We  also  find 
that  the  tabular  paradigm  for  input  is  an  interesting  alternative  to  the  input  lan¬ 
guage  for  the  SMV  tool.  We  provide  in  this  report  a  mechanical  translation  from 
the  tabular  dialogue  specification  into  SMV  and  provide  templates  or  heuristics 
for  various  reachability  analyses  using  the  Computation  Tree  Logic  (CTL)  for¬ 
malism.  This  research,  therefore,  presents  the  beginnings  of  two  significant 
contributions.  For  the  HCI  community,  we  show  how  model  verification  tools 
can  be  used  to  provide  a  more  powerful  analytic  technique  beyond  simulation  for 
the  specification  and  design  of  interactive  dialogues.  For  the  model  verification 
community,  we  demonstrate  the  possibility  of  developing  a  simpler  interface  to 
specify  and  analyze  certain  finite  state  machines. 
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1.  Introduction 


The  design  of  any  comp*  '.tern  is  an  incremental  process.  The  designers  have  coarse 
ideas  at  first.  They  must  try  out  these  ideas  and  refine  them  until  a  complete  design  specifi¬ 
cation  is  obtained.  It  is  not  cost  effective  to  implement  every  design  idea,  so  cheaper,  more 
abstract  models  are  built  to  explore  early  design  ideas.  A  model  may  take  the  form  of 
English  prose  descriptions,  sketches  of  screens,  executable  prototypes,  formal  specifica¬ 
tions,  or  user  manuals.  Whatever  form  it  takes,  a  good  model  is: 

•  easy  to  describe,  or  specify; 

•  easy  to  understand  and  communicate  its  meaning; 

•  readily  analyzable  to  determine  its  properties;  and 

•  easily  modified. 

There  are  usually  conflicts  among  the  four  desu  o  .  ibutes  identified  above.  Informal  tex¬ 
tual  descriptions  might  reduce  the  effort  for  descuptioi  and  communication,  but  they  are 
difficult  to  reason  about.  More  formal  models  have  the  advantage  of  applying  a  large  body 
of  mathematical  knowledge  to  proof  and  analysis,  but  they  are  typically  too  cumbersome 
and  difficult  for  use  by  average  programmers.  Prototyping  can  pr  >viJe  animated  simulations 
of  expected  system  behavior,  helping  to  uncover  problems  before  implementation,  but  it 
relies  on  human  interaction  with  the  prototypes  and  cannot  automatically  ve:/fy  certain 
properties  of  the  model. 

In  this  report,  we  will  examine  the  event-based  dialogs  which  are  used  to  model  interactive 
behavior  between  a  user  and  system.  These  dialogs  can  be  defined  at  a  very  high  level  of 
abstraction  for  use  in  early  interactive  system  design.  Specifically,  we  will  be  concerned 
with  Olsen’s  Propositional  Production  System  (PPS)  [2].  Monk  and  Curry  have  defined  a 
tabular  method  for  expressing  a  proper  subset  of  PPS  and  have  shown  how  it  can  be  imple¬ 
mented  on  a  standard  spreadsheet  package  to  provide  a  simulation  of  the  dialog  [3].  The  tab¬ 
ular  interface  to  PPS  has  several  advantages.  It  is  simple  to  define  and  understand  the  dialog, 
and  possible  to  validate  the  model  for  correspondence  to  high-level  task  requirements  in  the 
form  of  usage  scenarios.  The  dialog  can  easily  be  changed  to  suit  the  task  scenarios.  It  is  not 
possible,  however,  to  do  more  sophisticated  kinds  of  dialog  analysis,  such  as  determining  if 
certain  dialog  states  are  reachable,  or  if  certain  actions  are  always  reversible.  Olsen,  Monk 
and  Curry  have  started  to  address  these  deeper  analysis  techniques,  but  have  not  yet  shown 
how  a  more  powerful  analysis  technique  can  be  added  to  the  expressive  and  simple  tabular 
specification  [6]. 

The  main  contribution  of  our  work  is  to  demonstrate  how  existing  model  verification  tools 
can  be  linked  to  the  tabular  PPS  dialog  description  to  provide  more  powerful  analy.ses. 
Model  verification  is  an  area  of  research  of  increasing  importance  in  software  engineering. 
Its  basic  premise  is  that  a  system,  once  described  as  a  finite  state  machine,  can  be  subjected 
to  exhaustive  analysis  of  its  entire  state  space  to  determine  what  properties  hold.  The  main 
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drawback  of  this  approach  is  the  state  explosion  problem,  in  which  the  number  of  states  of 
the  system  increases  exponentially  as  it  becomes  more  and  more  complex.  Since  realistic 
examples  of  system  end  up  having  very  large  state  spaces,  exhaustive  search  was  considered 
too  expensive.  The  main  advances  in  model  verification  technology  now  allow  for  examina¬ 
tion  of  systems  with  huge  state  spaces  (over  10^®  states)  [8].  We  will  demonstrate  how  a  tab¬ 
ular  PPS  event-based  dialog  can  be  translated  into  one  particular  model  verification  tool,  the 
Symbolic  Model  Verifier  (SMV),  developed  at  CMU  [4]. 

The  link  between  tabular  event-based  dialog  specification  and  model  verification  which  we 
establish  in  this  report  represents  two  distinct  contributions.  First,  dialog  modeling  is  impor¬ 
tant  in  the  design  and  analysis  of  interactive  systems,  but  there  are  very  few  tools  or  tech¬ 
niques  for  doing  this.  Pre-condition  and  post-condition  semantics  of  low-level  interaction 
widgets  have  been  used  in  the  UIDE  system  to  automatically  generate  an  interface  from  its 
specification,  but  this  does  not  speak  to  the  analysis  of  the  specification  [2].  Probably  the 
closest  related  technique  to  one  we  are  proposing  would  be  the  Statemate  system  [13]  based 
on  Harel’s  statecharts  (11][12].  Statecharts  provide  a  visual  formalism  for  specifying  com¬ 
plicated  state  transition  systems  and  the  Statemate  system  provides  a  way  to  simulate  the 
specification  and  perform  certain  reachability  and  deadlock  checks  on  the  specification.  At 
this  point,  we  are  unable  to  say  how  our  approach  with  model  verification  and  tabular  speci¬ 
fication  compares  to  statecharts  and  Statemate. 

The  second  contribution  of  this  work  is  the  development  of  better  interfaces  for  model  veri¬ 
fication  technology.  The  advances  in  model  verification  that  have  enabled  the  efficient 
examination  of  complex  systems  with  many  states  have  not  been  accompanied  by  suitable 
advances  in  the  interfaces  to  those  tools.  One  of  the  major  obstacles  preventing  their  more 
widespread  adoption  is  that  the  tools  are  too  difficult  to  use.  By  demonstrating  the  mechani¬ 
cal  translation  from  the  tabular  event-based  dialog  description  into  the  SMV  tool,  we  are 
laying  the  foundation  for  an  enhanced  interface  to  SMV  which  should  prove  more  usable  for 
certain  applications. 

The  remainder  of  this  report  is  organized  as  follows.  Section  2  describes  the  overall  frame¬ 
work  of  our  method  and  clearly  indicates  how  our  work  translating  PPS  tabular  descriptions 
into  SMV  for  further  analysis  fits  into  an  overall  design  life  cycle.  In  Section  3.  we  provide 
an  overview  of  PPS  and  define  the  tabular  definition  of  PPS  dialog  mo<Jcls.  In  Section  4.  we 
provide  a  brief  overview  of  the  Computation  Tree  Logic  (CTL)  and  the  SMV  tool.  Section 
5,  the  first  significant  section  of  this  report,  explains  the  translatic  i  .step  from  a  PPS  tabular 
description  into  the  CTL  representation  of  SMV.  In  that  section,  we  define  the  mechanical 
steps  for  translating  from  P^  into  SMV  and  prove  that  the  translation  is  well-defined.  Sec¬ 
tion  6  presents  a  case  study  of  analysis  and  gives  a  guideline  of  how  certain  desired  proper¬ 
ties  can  be  cast  in  CTL  formulae.  Section  7  describes  ’itc  follow-up  activities  if  a  property 
does  not  hold  in  the  automatic  analysis.  Section  8  concludes  our  results  and  discus.ses  the 
future  work. 
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2.  The  Overall  Process  of  Dialog  Design 

This  section  describes  the  overall  dialog  design  process  and  the  role  that  both  PPS  and  SMV 
play  in  that  process.  The  method  we  are  advocating  is  divided  into  five  steps,  as  shown  in 
Figure  1  -  formulating  the  dialog  model  in  PPS,  validating  the  PPS  task  model  by  simula¬ 
tion,  mechanically  translating  the  dialog  model  into  SMV,  automatically  verifying  CTL- 
based  properties,  and  visualizing  the  design  problems  for  correction. 


Fifure  1.  The  dialog  desigii  proccaa 


2.1.  Dialog  Model  Formulation 

The  first  step  in  dialog  design  is  to  create  an  initial  dialog  description  ba.sed  on  an  under¬ 
standing  of  the  system  to  be  built  and  the  tasks  it  mu.sl  support.  Developing  an  adequate  task 
model  for  use  in  initial  design  of  an  interactive  system  is  a  rich  area  of  research  called  task 
analysis  (for  a  summary  of  task  analysis  approaches,  sec  Chapter  7  of  ( 1  ]).  Monk  &  Curry 
have  developed  a  scenario-based  method  for  generating  a  dialog  model.  There  are  several 
artifacts  which  result  from  their  method  (a  work  objective  decomposition,  descriptions  of 
illustrative  scenarios,  and  exceptions  lists),  but  the  principal  artifact  is  a  tabular  dialog 
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description  in  a  reduced  PPS  syntax  using  their  own  tool.  Action  Simulator,  a  specialized 
spreadsheet  package  [3].  The  work  in  this  paper  does  not  address  this  issue  of  dialog  formu¬ 
lation  any  further.  Rather,  we  are  more  concerned  with  how  a  dialog  description  can  be 
manipulated  and  analyzed. 

2.2.  Animated  Simulation  against  Task  Model 

The  development  of  a  good  dialog  model  requires  an  iterative  process.  Once  we  have  a  PPS 
tabular  specification,  it  is  not  difficult  to  evaluate  the  dialog  model  against  the  task  model  if 
there  is  some  computer  support.  Simulation  of  the  dialog  is  one  way  to  check  its  adequacy. 
In  Monk  &  Curry’s  work,  the  Action  Simulator  is  used  to  compare  a  dialog  model  against 
the  task  scenarios  used  to  develop  it.  This  requires  the  use  of  a  software  program  that  keeps 
a  record  of  what  conditions  are  set  and  uses  this  record  to  display  a  list  of  user  events  that 
are  available  for  selection.  The  designer  can  examine  the  effect  of  one  of  these  events  by 
selecting  it.  This  changes  the  dialog  state  and  a  new  list  of  available  user  events  is  displayed. 
The  designer  can  run  though  the  scenarios  in  the  task  model  and  check  that  the  model  allows 
the  user  to  generate  the  appropriate  user  events  and  whether  a  task  can  be  accomplished. 

Analysis  of  a  dialog  model  by  observing  its  behavior  in  this  way  is  useful  to  gain  an  under¬ 
standing  of  the  design.  However,  there  are  several  questions  a  designer  might  ask  that  are 
tedious  or  difficult  to  answer  by  exhaustive  simulation  of  the  dialog  itself.  For  example. 
Olsen,  Monk  &  Curry  [6]  list  several  varieties  of  reachability  properties  that  would  be  virtu¬ 
ally  impossible  to  check  using  the  Action  Simulator. 

23.  Mechanical  Translation 

Olsen,  Monk  &  Curry  also  propose  some  algorithms  to  perform  the  reachability  checks  on  a 
general  PPS  dialog,  but  they  do  not  provide  a  tool  for  performing  the  analysis.  Our  aim  in 
this  report  is  to  examine  to  what  extent  those  more  sophisticated  analyses  can  be  achieved 
by  model  verification  technology  that  already  exists.  The  model  checking  technique  is  very 
[womising  because  the  analysis  can  be  automated  and  the  kinds  of  properties  that  can  be  ver¬ 
ified  are  very  rich.  If  the  PPS  tabular  specification  were  mechanically  translatable  into  a 
form  acceptable  for  model  checking,  then  we  would  be  able  to  take  advantage  of  those  tools. 

A  large  part  of  this  report  is  devoted  to  the  transformation  process  from  a  PPS  specification 
into  the  SMV  input  language.  Both  PPS  and  SMV  are  finite  staue  systems.  However,  there 
are  differences  between  the  two  formalisms.  SMV  supports  the  Computation  Tree  Logic 
(CTL),  a  branching-time  temporal  logic  and  it  enforces  that  each  branch  of  the  computation 
tree  must  be  infinite.  PPS  dialogs  can  have  (te^locks.  PPS  have  a  collection  of  u.ser  events 
participating  in  the  dialog  state  transitions  but  SMV  must  encode  the  user  events  as  state 
information.  These  issues  should  be  carefully  addressed  in  the  translation  process. 

SMV  is  a  tool  which  can  accept  a  CTL  machine  and  CTL  specifications.  Based  on  our 
results.  It  should  be  straightforward  to  write  a  translator  converting  a  standard  PPS  table  into 
SMV.  The  translation  process  could  then  be  hidden  from  the  dialog  designer. 
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2.4.  Automatic  Property  Analysis 

There  are  certain  frequently  desired  properties  a  designer  might  want  to  assure  before  imple¬ 
mentation.  It  is  considered  a  poor  design  if  there  are  points  in  the  dialog  where  the  system 
might  deadlock,  if  tasks  are  unreasonably  difficult  to  complete,  or  if  effects  cannot  be 
undone.  Being  able  to  detect  such  potential  usability  problems  early  in  the  design  process  is 
a  considerable  advantage. 

Having  a  CTL  machine  represented  in  SMV  language  translated  from  a  PPS  dialog,  the 
designer  can  start  to  ask  questions  as  CTL  formulae  which  are  automatically  verified.  How¬ 
ever,  it  would  be  useful  if  we  could  identify  the  kinds  of  questions  that  are  usually  asked, 
and  provide  guidelines  for  how  to  express  the  questions  in  CTL  formulae.  We  summarize 
several  categories  of  questions  and  show  how  these  questions  can  be  cast  in  CTL  logic, 
based  on  the  properties  defined  by  Olsen,  Monk  &  Curry  [6]. 

2.5.  Design  Problem  Visualization 

The  SMV  model  checker  will  try  to  provide  a  counterexample  if  the  property  being  checked 
is  false.  These  counterexamples  are  output  in  a  log  file  and  relatively  difficult  to  trace,  espe¬ 
cially  when  the  state  space  is  very  large  and  complicated.  We  can  redirect  the  log  file  output 
by  SMV  to  drive  the  animation  tool.  In  this  way,  ihe  designer  can  easily  visualize  why  and 
how  the  desired  property  fails,  instead  of  tediously  tr:u:ing  the  log  file  and  often  getting  lost. 


3.  Propositional  Production  System 

3.1.  PPS  Dialog  Model 

Propositional  Production  Systems  were  originally  introduced  by  Olsen  and  used  to  specify 
human-computer  dialog  at  a  much  higher  level  of  abstraction  for  analysis  purpose  of  devel¬ 
oping  verification  algorithms  [6].  However,  production  systems  have  a  long  history  of  use 
for  nKxlelling  human-computer  dialog.  Tools  for  the  generation  of  user  interfaces  u.se  rules 
with  pre-  and  post-conditions  to  describe  the  behavior  of  an  interface,  and  automatically 
generate  a  user  interface  from  the  rule  specification  [2].  The.se  tools  have  as  their  objective 
the  low  level  specification  of  human-computer  dialog.  For  our  purpose,  it  does  not  matter 
whether  the  propositional  production  systems  are  used  at  a  higher  abstraction  level  (such  as 
"select  delivery  record  N")  or  in  a  low  level  physical  specification  (such  as  "release  the  left 
button").  We  simply  treat  PPS  as  an  easy-to-write  input  language  for  model  checking.' 

In  a  PPS  specification,  the  designers  identify  a  .set  of  u.ser  events  and  several  fields.  A  field  is 


I  ll  IX  generally  recognized  lhal  nndelling  al  a  more  abinract  level  can  enforce  anemion  on  cniical  ixxiiex  in  the  early  develop- 
menl  phaM  It  ix  eaxier  to  verify  a  dialog  model  againM  iner  xcenanox  if  the  dialog  model  ix  at  the  xame  level  of  abxtraction  as 
Ihe  talk  model. 
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associated  with  a  set  of  distinct  values.  At  any  time  a  held  can  only  be  in  one  of  the  values 
associated  with  it.  That  is,  the  values  associated  with  a  held  are  mutually  exclusive  so  set¬ 
ting  a  new  value  unsets  the  value  currently  set.  The  vector  of  current  values  of  all  helds  rep¬ 
resents  the  current  state  of  the  dialog  model.  The  designers  also  dehne  a  starting  state  vector 
and  a  collection  of  rules.  A  rule  takes  the  following  form: 

user  event,  pre-condition  vector,  post-condition  vector 

A  rule  attaches  a  pre-condition  vector  and  a  post-condition  vector  to  a  user  event.  The  pre- 
and  post-condition  vectors  are  written  in  propositional  logic  formulae  in  terms  of  helds.  A 
pre-condition  vector  specihes  when  a  rule  is  enabled;  a  rule  is  enabled  if  the  current  state  of 
the  dialog  model  makes  the  pre-condition  vector  of  that  rule  true.  A  user  event  is  enabled  if 
the  rule  is  enabled.  Depending  on  the  current  state,  there  are  probably  zero,  one,  or  more 
enabled  user  events.  Each  time  a  user  can  select  one  user  event  to  execute  from  the  set  of 
enabled  user  events.  The  rule  of  the  selected  user  event  then  hres.  The  post-condition  vector 
of  the  bring  rule  changes  the  state  of  the  dialog  model,  which  becomes  the  conditions  for  the 
next  rule  to  hre. 

3.2.  PPS  Copier  Example 

Table  1  shows  a  PPS  speciheation  example  of  a  copier  taken  from  [3].  Ip  this  case,  each  held 
is  associated  with  binary  values  but  in  general  it  is  not  necessary.  The  collection  of  rules  are 
described  using  a  tabular  form.  Each  rule  takes  one  row  and  has  a  user  event  name  associ¬ 
ated  with  it.  The  top  line  of  each  row  specihes  the  pre-condition  vector  and  the  bottom  line 
of  each  row  specihes  the  post-condition  vector.  If  a  held  is  blank  in  a  pre-condition  vector, 
this  indicates  that  we  don’t  care  about  the  value  of  that  held  when  deciding  if  the  rule  is 
enabled.  If  a  held  is  blank  in  a  post-condition  vector,  this  indicates  that  the  value  of  that  Held 
will  not  be  changed  if  the  rule  hres.  With  the  starting  state  of  (Ready=NoiOK,  Copying-Off, 
OneCopy-Yes,  DefSettings=Yes),  only  rule  1  is  enabled  and  thus  the  user  can  only  choose 
the  user  event  SwitchOn  to  execute.  After  bring  rule  1,  the  state  becomes  (Ready=OK, 
Copying-Off,  OneCopy=Yes,  DefSettings^Yes),  and  therefore  rules  2,  3,  5,  and  7  are  now 
enabled.  This  means  that  the  user  events  SwitchOff,  Copy,  MultipleCopies,  and  ChangeSet- 
tings  are  enabled  and  the  user  can  select  any  one  of  the  four  events  to  carry  on.  The  selection 
is  made  by  the  user  and  hence  the  state  of  the  dialog  model  is  essentially  determined  by  both 
the  rules  coded  in  the  table  and  the  user’s  selection. 

Rekto  Ready:  { OK,  NotOK } 

Copying:  { On,  Off } 

OneCopy:  { Yes,  No } 

DefSettings:  { Yes,  No } 

Initial  state :  (Ready  NotOK,  Copying  =  Off,  OneCopy  =  Yes,  DefSettings  =  Yes) 


Rule 

user  event 

Ready 

Copying 

OneCopy 

DefSettings 

1 

SwitchOn 

NotOK 

OK 

Rule 

user  event 

Remly 

Copying 

OneCopy 

OefSettings 

2 

SwitchOH 

OK 

NotOK 

Off 

3 

Copy 

OK 

Off 

On 

■ 

RnishedCopying 

OK 

On 

Off 

5 

MultipleCopies 

OK 

Off 

Yes 

No 

6 

CancelCopjes 

OK 

Off 

No 

Yes 

■ 

ChangeSettings 

OK 

Yes 

No 

8 

CancelSettings 

OK 

No 

Yes 

Table  1.  PPS  specificatioii  of  a  copier 


3.3.  Expressiveness  of  PPS  Description 

A  PPS  specification  of  this  kind  is  relatively  easy  to  read  and  write.  PPS  is  similar  to  a  state 
transition  diagram  in  that  it  consists  of  rules  specifying  possible  state  transitions.  State  tran¬ 
sition  diagrams  are  a  representation  most  programmers  are  familiar  with.  The  problem  with 
using  a  simple  state  machine  to  model  a  complex  system  is  that  the  large  number  of  parallel 
options  leads  to  a  state  explosion  that  makes  specification  and  analysis  intractable.  PPS 
resolves  this  problem  by  working  at  the  granularity  of  state  sets  instead  of  every  single  state. 

Notice  that  the  pre-  and  post-condition  vectors  and  the  starting  state  vector  do  not  have  to  be 
a  full  vector.  The  absence  of  a  value  of  a  field  in  a  vector  simply  means  “don’t-care”  in  a 
starting  state  (actually  the  set  of  starting  states  is  more  correct),  means  “don’t-care”  in  a  pre¬ 
condition,  or  means  “don’t-change”  in  a  post-condition.  In  this  way,  PPS  avoids  the  neces¬ 
sity  of  enumerating  the  entire  state  space.  A  key  to  the  expressiveness  of  a  PPS  specification 
is  the  use  of  incomplete  condition  vectors  to  describe  a  wide  variety  of  possible  states.  For  a 
large  system,  the  number  of  rules  needed  in  a  PPS  specification  is  much  less  than  the  num¬ 
ber  of  transitions  needed  in  a  typical  state  machine  specification. 

In  addition,  our  PPS  model  also  allows  non-determinism  to  enhance  its  expressiveness.  At 
any  time  during  the  course  of  the  dialog,  there  is  a  set  of  enabled  rules.  It  is  possible  to  let 
multiple  rules  have  the  same  event  label,  and  therefore  it  is  possible  to  have  multiple  rules 
with  the  same  event  label  being  enabled  simultaneously.  Given  the  .same  event  label,  any 
enabled  rule  with  that  event  label  can  fire  but  only  one  can  fire.  The  decision  of  which  one  to 
take  is  non-deterministic.  It  is  arguable  that  in  the  high  level  design,  it  is  a  desired  feature  to 
allow  non-determinism.  The  designer  can  specify  the  essential  execution  paths  in  a  deter¬ 
ministic  way  while  ignore  others.  Besides,  the  CTL  model  we  adopt  for  automated  verifica- 
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tion  well  supports  non-determinism.  * 

34.  Formalism  of  PPS 

Suppose  N  is  the  number  of  rules  in  a  PPS  specification,  and  each  rule  i  is  in  the  form  of  (a,, 
prei,  posti).  Formally,  a  PPS  system  is  a  triple  PPS  =  (A,  I,  T)  where 

•  A  is  a  finite  set  of  event  labels;  that  is,  A  =  /  u, !  f  <  /  <  N  /. 

•  Z  is  a  finite  set  of  dialog  states. 

•  r  is  a  binary  relation  where  Ts;  A  x  fZ  — ^  in  which  each  member  specifies  one 

rule;  that  is,  T  =  /  (oj,  transj)  I  I  <i<N  }. 

We  denote  the  domain  of  trans^  by  pre^  and  the  range  of  tranSf  by  postj.  Each  pair  of  (pre^, 
posti)  ^  actually  a  partial  function  tranSi  of  signature  Z  Z,  which  maps  a  full  pre¬ 
state  vector  to  a  full  post-state  vector. 


4.  Model  Checking  Technologies 

4.1.  Computation  lYee  Logic 

Temporal  logic  and  model  checking  have  been  used  to  verify  properties  in  hardware  sys¬ 
tems.  To  apply  model  checking  techniques,  one  needs  to  transform  the  system  to  be  verified 
into  an  appropriate  structure  that  the  model  checking  tool  can  accept.  One  then  specifies  the 
property  needed  to  be  ensured  in  a  logic  formula  and  the  tool  automatically  analyzes  the 
structure  and  tells  whether  the  property  holds  in  the  system.  The  specification  language  is  a 
propositional,  branching-time  temporal  logic  called  CTL  (Computation  Tree  Logic). 

The  semantics  of  CTL  formulae  can  be  understood  with  respect  to  a  labeled  state-transition 
graph.  Formally,  suppose  that  AP  is  the  underlying  set  of  atomic  propositions,  we  can  define 
a  CTL  machine  to  a  triple  CTL  =  (S,  R,  P)  where 

•  S  is  a  finite  set  of  states. 

•  /?  is  a  binary  relation  on  5  (/?  G  5  x  5)  which  gives  the  possible  transitions  between 
states  and  must  be  total;  that  is,  V  x  e  5  •  (3  y  e  S*(x,  y)G  R). 

•  P;  5  — >  2^^  assigns  to  each  state  the  set  of  atomic  propositions  true  in  that  state. 

A  path  is  an  infinite  sequence  of  states  (sq,  s/,  $2,  ■■■)  such  that  V  /  •  (.v,,  gR.  For  any 
machine  CTL  =  (S,  R,  P)  and  any  state  sg  e  5,  there  is  an  infinite  computation  tree  with  root 
labeled  sq  such  that  r  — >  r  is  an  arc  in  the  tree  iff  (s,  t}G  R.  Figure  2  shows  a  CTL  machine 
and  the  associated  computation  tree  rooted  at  sg. 


I .  The  sHiMUon  of  having  two  enabled  rules  simply  means  two  branching  paths.  We  can  coastract  a  CTL  machine  where  both 
pailtf  exist  in  the  computation  tree. 
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Figure  2.  CTL  machine  and  the  corresponding  tree  for  starting  state  Sq 

CTL  operators  permit  explicit  quantification  over  all  possible  futures.  The  syntax  and 
semantics  for  CTL  formulae  are  defined  in  [7]  and  are  only  summarized  as  follows: 

•  Every  atomic  proposition  is  a  CTL  formula. 

•  If/and  g  are  CTL  formulae,  then  so  are  ~  f,f  &  g,f\  g,f  — >  g,  AX  f,  EXf,  A[f  U  g]. 

Elf  U  g],  AFf,  EFf,  AGf  EGf 

The  symbols  -  (not),  &  (and),  and  I  (or)  are  logical  connectives.  These  connectives  and  their 
derivable  propositions,  such  as/-»  g  (/'implies  g),  have  their  usual  meanings.  X  is  the  next¬ 
time  operator.  The  formula  AX/ (EX  f)  intuitively  means  that  formula  /holds  in  every  (in 
some)  immediate  successor  of  the  current  state.  U  is  the  until  operator,  and  the  formula  A(f 
U  g]  {E[fU  gj)  intuitively  means  that  along  every  (some)  computation  path  there  exists  an 
initial  prefix  of  the  path  such  that  g  holds  at  the  last  state  of  the  prefix  and/holds  at  all  other 
states  along  the  prefix.  The  formula  AF  f{EF  f)  means  that  along  every  (some)  path  there 
exists  some  future  state  in  which  /  holds.  The  formula  AG  f  {EG  f)  means  that  /  holds  in 
every  state  along  every  (some)  path. 

Taking  the  above  copier  example,  perhaps  we  will  want  to  check  if  the  copier  can  be 
switched  off  at  any  time  when  the  copier  is  on.  The  corresponding  CTL  formula  would  look 
like  follows. 

AG (Ready  =  OK  ->  EX (Ready  =  NotOK) ) 


4.2.  Symbolic  Model  Verifier 

SMV  is  a  model  checker  which  accepts  a  CTL  machine  and  a  CTL  formula,  and  automati¬ 
cally  tests  whether  or  not  the  formula  holds  in  the  machine.  If  the  SMV  model  checker 
determines  the  formula  is  true,  then  the  property  holds  in  the  CTL  machine  and  also  in  the 
system  from  which  the  CTL  machine  is  translated. 
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The  primary  purpose  of  the  SMV  input  language  is  to  describe  the  transition  relation  of  a 
CTL  machine.  A  detailed  description  of  the  syntax  and  semantics  of  the  SMV  input  lan¬ 
guage.  and  the  function  of  the  SMV  model  checker  can  be  found  in  [4]. 

If  any  of  the  specifications  does  not  hold  in  the  CTL  machine,  the  SMV  model  checker  will 
attempt  to  produce  a  counterexample,  proving  that  the  specification  is  false.  Some  formulae 
require  infinite  execution  paths  as  counterexamples.  In  this  case,  the  model  checker  outputs 
a  looping  path  up  to  and  including  the  first  repetition  of  a  state.  However,  generating  a  coun¬ 
terexample  is  not  always  possible,  since  formulae  preceded  by  existential  path  quantifiers 
cannot  be  proved  false  by  showing  a  single  execution  path. 

SMV  model  checker  needs  to  exhaustively  search  the  state  space.  The  BDD-based  (Binary 
Decision  Diagram)  symbolic  model  checking  algorithm  makes  it  possible  to  efficiently 
determine  whether  specifications  expressed  in  CTL  formulae  are  satisfied  [?].  We  will  not 
explore  this  topic  as  it  is  far  out  of  the  scope  of  this  report. 


5.  Translation  of  Tabular  Description  into  SMV 


5.1.  Mimicking  User  Events 

In  a  PPS  specification,  each  rule  is  associated  with  a  user  event.  A  user  event  is  enabled  if 
the  current  state  makes  the  pre-condition  vector  of  the  rule  true.  At  any  time,  the  number  of 
the  enabled  user  events  could  be  zero  or  more.  If  there  are  zero  enabled  user  events,  this 
means  the  dialog  enters  into  a  deadlock,  and  the  user  cannot  do  anything.  If  there  are  more 
than  zero  enabled  user  events,  then  the  user  can  select  one  of  them  to  execute.  Each  time 
after  a  rule  fires,  the  current  state  is  changed  according  to  the  post-condition  vector  of  the 
rule,  and  a  new  collection  of  enabled  user  events  should  be  determined  for  u.ser’s  next  .selec¬ 
tion. 

The  above  description  will  probably  give  readers  a  dynamic  impressior  as  someone  exe¬ 
cutes  the  PPS  dialog.  Essentially,  after  a  PPS  table  is  defined,  a  state  machine  is  already  stat¬ 
ically  defined.  Given  any  state,  the  collection  of  enabled  user  events  from  that  state  can  be 
easily  computed  by  examining  each  rule.  Consequently,  if  we  treat  a  user  event  name  as  an 
input  symbol,  a  user  event  name  is  simply  like  an  alphabet  accepted  by  FA  (finite  automa¬ 
ton). 

More  precisely,  a  user  event  name  is  like  an  alphabet  accepted  by  NFA  (non-deterministic 
finite  automaton)  because  NFA  allows  (i)  zero,  (ii)  one,  or  (iii)  more  transitions  from  a  state 
on  the  same  input  symbol.  Case  (i)  means  that  at  a  dialog  state,  a  particular  u.ser  event  E  is 
not  enabled,  and  thus  the  user  cannot  select  it.  Case  (ii)  means  that  at  a  dialog  state,  a  partic¬ 
ular  user  event  E  is  enabled,  and  there  is  only  one  rule  making  the  user  event  E  enabled. 
Case  (iii)  means  that  at  a  dialog  state,  a  particular  user  event  E  is  enabled,  and  there  is  more 
than  one  rule  making  the  user  event  E  enabled.  Case  (iii)  is  allowed  because  we  allow  multi¬ 
ple  rules  to  have  the  same  event  label.  This  problem  is  dealt  with  in  Section  5.2. 
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The  problem  of  using  a  CTL  machine  to  mimic  a  PPS  system  is  that  the  CTL  model  does 
not  include  the  concept  of  alphabets  explicitly.  The  transition  relation  is  specified  by  a  for¬ 
mula  which  confines  the  relationships  of  the  state  vectors  between  two  states;  there  exi't^  a 
transition  between  two  states  if  the  two  state  vectors  together  make  the  formula  true. 

To  model  the  user  events,  our  strategy  is  to  group  all  possible  user  event  names  of  a  PPS 
table  into  an  event  type,  and  declare  a  special  state  variable.  Event,  whose  value  always 
denotes  an  enabled  user  event.  This  implies  that  the  “event  value”  has  become  part  of  the 
state  information.  This  also  implies  that  in  the  resultant  CTL  machine,  the  corresponding 
computation  tree  will  only  contain  nodes  each  of  whose  Event  variable  represents  an 
enabled  user  event;  any  other  node  (i.e.,  a  dialog  state  with  an  non-enabled  user  event,  or 
simply  an  unreachable  dialog  state)  should  not  emerge  in  the  computation  tree. 

Also,  It  is  possible  to  have  a  deadlock  in  a  PPS  specification.  In  a  CTL  machine,  however, 
each  branch  of  the  computation  tree  has  an  infinite  trace.  The  deadlock  modelling  problem 
is  dealt  with  in  Section  5.3. 

5.2.  Non-determinism 

There  are  two  ways  to  specify  transition  relations  of  a  CTL  machine  and  its  initial  states  in 
SMV.  They  can  be  specified  by  a  collection  of  parallel  assignments,  introduced  by  the 
ASSIGN  statements,  or  by  propositional  formulae  directly,  introduced  by  the  TRANS  and 
INIT  statements. 

An  ASSIGN  statement  usually  involves  lots  of  case  expressions.  The  value  of  a  case  expres¬ 
sion  is  determined  by  the  first  expression  on  the  right  hand  side  of  a  colon  such  that  the  con¬ 
dition  on  the  left  hand  side  is  true.  This  means  that  if  we  use  this  way  to  specify  transition 
relations,  only  one  rule  will  fire  when  the  same  user  event  can  fire  two  rules. 

Consider  a  very'  simple  but  strange  PPS  specification.  Only  one  user  event  el  is  defined  and 
X  is  the  only  state  variable.  Initially  the  value  of  x  is  a.  Rule  2’s  pre-condition  is  true  and 
therefore  subsumes  rule  1 . 


Rule 

user  event 

X 

1 

el 

a 

b 

2 

el 

c 

An  SMV  program  using  ASSIGN  statements  might  look  as  follows. 

MODULE  main 
VAR 

Event  ;  {  el  }  ; 

X  ;  {  a ,  b ,  c  )  ; 


ASSIGN 


puKr  /A 


init(x)  :«  •; 
n*xt(x)  :« 

c«a« 

Bwnt  «  •!  b  X  s  a  :  b: 
Bvant  >  •!  :  c; 

I  :  X. 

•aac . 


We  expect  that  there  exists  a  next  state  in  which  x  ish  and  also  a  next  state  in  which  x  is  i  . 
However,  the  verification  results  tell  us  the  latter  is  not  true.  This  is  because  the  case 
expression  textually  imposes  a  priority  order  on  the  conditions. 

SPEC  EX(x  °  b)  SMV  raporca  Chat  this  spacif ication  is  crua 
SPEC  EX(x  =  c)  --  SMV  reports  that  this  specification  is  false 

Alternatively,  we  may  use  the  TRANS  and  INIT  statements.  It  is  possible  in  SMV  to  specify 
the  transition  relation  directly  as  a  propositional  formula  in  terms  of  the  current  and  next 
values  of  the  state  variables.  Any  current/next  state  pairs  is  in  the  transition  relation  iff  they 
make  the  formula  true.  Similarly,  it  is  possible  to  give  the  set  of  possible  initial  states  as  a 
formula  in  terms  of  only  current  state  variables.  An  SMV  program  modeling  the  same 
example  using  this  alternative  shows  that  both  specifications  are  true. 


MODULE  main 
VAR 

Event  :  (  el  ) ; 

X  :  {  a,  b,  c  ); 

INIT  X  =  a 

TRANS  (Event  =  el  i  x  =  a  4  nexc(x)  =  b)  | 

(Event  =  el  &  next(x)  =  c)  j 

(  (((Event  =  el  4  x  =  a)  |  (Event  =  el))  4  next(x)  =  x) 

SPEC  EX(x  =  b)  --  SMV  reports  that  this  specification  is  true 

SPEC  EX(x  =  c)  --  SMV  reports  that  this  specification  is  true 

The  SMV  literature  does  not  recommend  the  use  of  TRANS  and  INIT  since  it  is  possible  to 
write  logical  absurdities  using  these  features  [4].  For  example,  one  could  specify  the  logical 
constant  0  to  represent  the  transition  relation,  resulting  in  a  system  with  no  transitions  at  all. 
However,  the  above  example  justifies  our  need  to  use  these  features.  Because  they  are  dan¬ 
gerous,  it  is  the  responsibility  of  those  writing  translators  to  ensure  appropriate  use  of 
TRANS  and  INIT  statements.  We  will  fulfill  this  responsibility  in  Section  5.5. 

53.  Deadlock 


A  CTL  computation  tree  cannot  have  finite  traces.  That  is,  given  a  current  state,  there  must 
exist  at  least  one  successor.  However,  a  PPS  specification  might  have  a  deadlock.  This 
means  that  at  some  point  none  of  the  rules  are  enabled,  and  hence  none  of  the  user  events 
can  be  selected. 

We  resolve  this  situation  by  defining  a  special  “stuck”  event.  When  a  PPS  dialog  gets  into  a 
deadlock,  the  user  can  only  take  the  stuck  event  and  remains  stuck  forever.  From  the  CTL 
machine’s  point  of  view,  there  is  still  a  “null”  transition  when  the  deadlock  happens.  The 
logical  condition  for  deadlock  is  the  complement  of  the  disjunction  of  all  rule’s  pre-condi- 


Consider  a  very  simple  example  as  follows.  Two  user  events  e!  and  e2  are  defined  and  i  is 
the  only  state  variable.  Initially  the  value  of  i  is  a  Therefore  only  event  rl  can  he  taken  and 
X  becomes  b.  Since  the  current  state  is  h.  only  event  e2  can  be  taken  and  r  becomes  <  Now 
the  current  state  is  c  and  neither  of  the  rules  are  enabled  So  the  dialog  gets  into  a  deadiiK'k 


Rut* 

u**r*v*nl 

X 

1 

•1 

a 

b 

2 

*2 

b 

c 

An  SMV  translation  is  as  follows.  In  addition  to  the  normal  user  events,  a  special  stuck 
event  is  included  in  the  event  declaration.  For  conciseness,  we  use  DEFINE  statements, 
which  are  analogous  to  macro  definitions  in  an  ordinary  programming  language.  Two  mac¬ 
ros  are  defined  for  each  rule:  one  corresponds  to  the  pre-condition  vector;  the  other  corre¬ 
sponds  to  the  post-condition  vector.  no_enabled  denotes  the  situation  where  none  of  the 
rules’  pre-condition  are  satisfied,  default  denotes  that  the  dialog  state  does  not  change  at 
all  (when  it  is  stuck). 


MODULE  main 

VAR 

x;  fa,  b,  c); 

Event:  {el,  e2.  Stuck}; 

DEFINE 

prel  :=  X  =  a; 
pre2  ;=  X  =  b; 

no_enabled  :=  !  (prel  |  pre2); 
postl  :=  next(x)  =  b; 
post2  :=  next(x)  =  c; 
default  :=  next(x)  =  x; 

INIT  --  assign  initial  states 
(X  =  a)  St 

--  restrict  user  events  to  only  those  which  are  enabled 
--  if  no  user  event  is  enabled,  then  the  system  gets  stuck 
((prel  &  Event  =  el)  | 

(pre2  &  Event  =  e2)  | 

(no.enabled  &  Event  =  Stuck) ) 

TRANS  --  execute  transitions  specified  liy  the  rules 
((Event  =  el  &  prel  &  postl)  | 

(Event  s  e2  &  pre2  &  post2)  { 

(Event  =  Stuck  &  no_enabled  &  default) )  & 

--  restrict  user  events  to  only  those  which  are  enabled 
--  if  no  user  event  is  enabled,  then  the  system  gets  stuck 
((next(prel)  &  next(Event)  =  el)  | 

(next(pre2)  i  next (Event)  =  e2)  | 

(next (no_enabled)  &  next (Event)  =  Stuck)) 


Notice  that  in  the  INIT  statement,  the  first  part  is  to  assign  the  initial  states  and  the  second 
part  is  to  decide  the  enabled  user  events.  In  the  TRANS  statement,  the  first  part  is  to  assign 
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values  according  to  the  post-conditions  and  the  second  part  is  to  decide  the  enabled  user 
eveiMs  in  the  next  state.  Notice  that  next  ( preN )  means  that  the  next  state  satisfies  the  pre¬ 
condition  of  rule  N. 

5.4.  Sunmuiry  of  TVanslation  Steps 

1 .  Declare  the  necessary  state  variables  of  the  PPS  dialog  model. 

2.  Declare  the  user  events  of  the  PPS  dialog  model  plus  a  special  stuck  event. 

3.  For  each  rule,  define  a  macro  to  capture  the  pre-condition  vector. 

4.  Define  a  macro  which  is  the  negation  of  the  disjunction  of  all  pre-conditions. 

5.  For  each  rule,  define  a  macro  to  capture  the  post-condition  vector. 

6.  Define  a  macro  which  specifies  that  the  state  of  the  dialog  model  does  not  change 

7.  Write  down  the  INIT  statement  which  is  a  conjunction  of  two  parts.  The  first  part 
specifies  the  starting  states.  The  second  part  specifies  which  user  events  are  ini¬ 
tially  enabled. 

8.  Write  down  the  TRANS  statement  which  is  a  conjunction  of  two  parts.  The  first 
part  specifies  the  next  state  of  the  dialog  model  according  to  the  post-conditions. 

The  second  part  specifies  which  user  events  are  enabled  in  the  next  state. 

The  above  steps  are  a  mechanical  translation  process  and  can  be  easily  programmed. 

5.5.  Justificatioiis 

Formally,  we  are  constructing  a  CTL  machine  which  models  the  PPS^  specification.  PPS^  is 
derived  from  PPS  augmented  by  one  additional  rule  to  handle  the  deadlock.  Suppose  a/^+/ 
is  the  special  “stuck”  event.  PPS^  =  (A^,Z,  T^)  where 

•  A ^  is  the  set  of  user  events  plus  the  stuck  event;  that  is,  =  A  u  /  /,  where 

ayv+y «  A. 

•  £  is  the  set  of  dialog  states  as  defined  in  the  original  PPS. 

•  is  a  binary  relation  where  C  A^  x  — >  £),  which  additionally  includes  one 

rule  to  deal  with  the  deadlock;  that  is,  7^  =  Tu  /  fa/v+/,  trans/^+i) },  where  prej^^i 
=  Z  - prci  =  dom  irons and  transf^^./  is  an  identity  function  of  Z. 

liiiS 

The  domain  of  transu^^./  is  the  complement  of  the  union  of  all  other  rules’  pre-conditions.  It 
maps  any  state  vector  to  the  same  vector. 

The  translated  SMV  program  essentially  builds  a  machine  of  CTL  =  (S,  R,  P)  where 
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•  5  is  the  set  of  states  each  of  which  combines  a  user  event  with  a  dialog  state  (5  £ 

A^x  1). 

•  /?  is  a  binary  relation  where  R^(A^  xI.)x(A^  xl.)  which  gives  the  possible  tran¬ 
sitions.  Observing  the  logic  formula  specified  in  the  TRANS  statement,  there  are 
essentially  two  pieces:  the  first  piece  specifies  the  transition  of  the  dialog  state 
according  to  the  rules  while  does  not  specifies  the  value  of  the  next  event;  the  sec¬ 
ond  piece  specifies  the  value  of  the  next  event  according  to  the  value  of  the  next 
dialog  state  while  ignores  the  values  of  the  current  state.  Thus  literally  translating 
the  logic  formula  into  a  set  notation,  we  obtain 

R-^  {  ((ai,  s),  (a s’))  \  (s,  s')  e  transi  a  a '  €  A^  ) 
n 

LJ  /  ((a,  s),  (Oj,  s’ ))  \  ae  A^  a  s  e  ZAs’e  dom  transj  } 

/  S/SA/+/ 

•  P:  S  2^^  assigns  to  each  state  the  set  of  atomic  propositions  true  in  that  state. 

To  justify  that  CTL  is  a  valid  translation  of  PPSK  we  need  to  argue  that  for  given  user  events 
e  and  e’  and  dialog  states  v  and  v',  the  following  holds; 

((e,  v),  (e’,  v’))  e  /?  <=>  fv.  v’j  €  T^.e  a  v'  €  dom  T^e’)^. 


Proof: 

T^.e  =  /  tranSi  \  a,  ■=  e,  I  <i<  N-^1  } 

s  (  (s,  s’)  \  (s,  s’)  e  tranSj  a  u,  =  <?.  /  <  i  <  N+1  }. 

'U  .e’  =  KJ  {  tranSj  \  Oj-  e’,  I  <j  <  N+l  } 

=  /  (s’,  s”)  I  (s’,  s”)  €  tranSj  auj  =  e',  I  ^  A/+/  /. 

dom  f'sJ  T^.e')  ~  {  s’  \  s’  e  dom  transj  a  oy  =  e’.  I  ^  N+1 }. 

({e,  V).  (e’,  v’))  €  R 

<=>  ((e.  v),  (e’,  v’))G  KJ  {  i(ai,  s),  (a’,  s’))  I  f5,  €  tranSf  a  a’  €  A^  } 

n 

{  ((a,  s),  (Oj.  s'))\a€  A^  AS€  Z  a  .v’  €  dom  transj  } 
<=>  ((e.  v),  (e’.  v’))  e  ^  {  ffa,,  s),  (a’,  s’))  I  (s.  s’)  e  transi  a  a’  e  A^  ) 

/<tS/V+/ 

A 

((e,  v).  (e’,  v’))  e  /  ((a,  s),  (aj.  s’))\ae  A^  asg  Las'  e  dom  transj  / 


I .  The  nouiion  R.s  denote.*!  the  !!et  of  all  the  secondary  values  of  pairs  which  conrspond  to  .<  in  a  binary  lelalion  R.  that  is.  R.s 
=ifl\(s.O€R  }. 
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liliN*! 

(e,  V,  v')€  KJ  { (Uj,  s.  s')\  (s.  s’)  €  transj }  [for  the  argument  of  e=.  e’  €  A^\ 

A 

(e\  v’)e  KJ  /  (Oj,  s’)  \  s'  e  dom  transj  }  (for  the  argument  of  c=,  t*  e  and  v  e  I] 

liliN*! 

<=>  (e,  V.  v’)  e  /  fa,.  5.  s')  I  (s,  s')  €  transj  I 

/  S  I  S  /V4-  /  A  y,  ■  r 

A 

fe'.  v’)  €  ^  f  (oj,  s’)  \  s'  €  dom  Iransj  f 

I  All,  ■  r 

<=>  (e,  V,  v')e  /  fa,,  j.  s')  I  {s.  s')e  transj  a.  =  e  i  ^  i  <  A/+/  } 

A 

(e',  v')e  ( (Oj,  s’)  \  s’  e  dom  transj  /\  oj  =  e’  a  I  <j  ^  N+1  ) 

<=>  fv.  v’j  €  /  {s,  s’)  I  (s,  s’)€  tranSf  a  a,  =  e  a  /  S  1  <  N+l  } 

A 

v'  €  {  s’  \  s’  €  dom  tranSj  a  Uj  =  e'  a  I  <j  ^  N-^1  } 

«  fv.  v’j  €  ^^e  A  v’  €  dom  (KJ  T^.e’).  □ 

To  justify  that  the  transition  relation  in  CTL  has  no  finite  traces,  we  need  to  argue  that  there 
always  exists  a  successor  for  a  reachable  state;  that  is.  we  need  to  show  the  following; 

ffe.  v),(e’,  v’))€.  /?  =>  3  e’*  €  /4^  v”  €  Z  •  ((e’.  v’),  (e“,  v”))  e  R. 

Proof; 

From  the  definition  of  R  and  the  hypothesis  of  ffe,  v),  (e’,  v ’))  e  R,  we  can  infer  that 
3  X  /  ^  X  S  N+1  •  Ojf  s  ^ ’  A  v’  €  dom  trans^. 

Let  v”  =  irons j^v').  We  also  know  that  irons j^v')  e  Z  and  Z  =  ^  dom  irons 

liiiN*l 

Therefore,  v”  €  LJ  dom  irons This  implies  that 

/  iiiN*l 

3y.  1  ^y^N+ 1  •v”  G  dom  ironsy 

Let  e”  =  Oy  Then  ((e’,  v’j,  (e".  v”))  =  ((o^  v’j.  fa^  v”jj.  Given  the  definition  of  /?, 

((o^  v’j,  (Oy  v”jj  e  LJ  /  ffaj,  sj.  (o’,  s’))  I  fs,  j.’j  e  tronsj  a  a’  e  A^  } 

n 

LJ  { ffa,  sj,  fa*  s’jj  I  a  €  i4^  A  j  e  E  a  s ’  €  dom  rrans,  / 
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6.  Verification  of  Properties 

Various  properties  can  be  analyzed  against  the  PPS  dialog  in  the  translated  CTL  machine.  In 
Section  6.1.,  we  present  a  PPS  dialog  of  a  schedule  organizer  and  use  our  translation  tech¬ 
nique  to  construct  a  SMV  program  for  it.  In  Section  6.2.,  we  identify  several  categories  of 
questions  and  provide  CTL  templates  for  expressing  these  questions.  In  Section  6.3.,  we 
summarize  a  list  of  insights  that  we  discovered  in  our  attempt  of  establishing  templates. 

6.1.  PPS  Dialog  of  a  Schedule  Organizer 

The  example  comes  from  a  product  of  a  well-known  brand.  The  detailed  features  have  been 
abstracted  away  and  only  the  essential  functionality  is  captured.  A  user  can  turn  the  orga¬ 
nizer  on/off,  and  the  organizer  is  divided  into  several  modes:  schedule,  calendar,  telephone, 
memo,...  etc.  A' user  can  access  a  mode,  select  a  day,  edit  an  appointment  for  a  day,  view  a 
day’s  schedule,  overview  a  month’s  schedule,  delete  an  appointment,  and  perform  some 
other  actions  like  checking  memo  and  searching  a  phone  number. 

We  abstractly  model  the  organizer  with  three  modes:  Calendar,  Schedule,  and  Other.  A  user 
can  switch  the  power  On  and  Off.  The  field  of  Today  records  whether  currently  the  system  is 
at  today.  The  field  of  TargetDay  records  whether  currently  the  system  is  at  a  user’s  desired 
day.  The  field  of  Editing  records  whether  a  user  is  editing  an  appointment.  The  field  of 
Saved  records  whether  there  is  an  appointment  being  edited  without  being  saved.  The  PPS 
dialog  is  written  in  Table  2.  Notice  that  the  post-conditions  of  certain  rules  are  intentionally 
specified  in  a  non-deterministic  way.  For  example,  when  the  action  of  SwitchOn  is  taken,  the 
system  will  lead  to  today  as  the  current  day  but  whether  it  is  a  user’s  desired  day  is  the  user's 
decision.  Thus  rules  1  and  2  are  written  for  the  SwitchOn  action  and  the  post-condition  of 
TargetDay  can  be  either  Yes  or  No.  Also  notice  th^  we  put  no  limit  on  the  number  of 
appointments  for  a  day.  After  selecting  a  desired  day,  a  user  can  view  the  appointments  for 
that  day  in  sequence  by  continuously  taking  the  ViewNext  action.  To  signal  that  the  appoint¬ 
ments  for  a  desired  day  have  all  been  viewed,  the  post-condition  of  TargetDay  is  changed 
from  Yes  to  No.  However,  this  change  is  also  a  non-deterministic  decision  since  the  dialog 
model  does  not  record  how  many  appointments  there  are  for  each  day.  Four  rules  are  written 
for  the  ViewNext  action,  because  of  the  non-determinism,  and  because  of  the  interaction 
between  Today  field  and  TargetDay  field. 

FMdl  Po«Mr{On.OII} 

Mode:  { Schedule.  Celender,  Other ) 

Todey,  TugeiOey,  EdNmg,  Seved:  ( Yee,  No ) 
inWel  iwe :  (Power^Otl.  Mode^Odier.  EdWng>No.  Seved>Yee) 


Rule 

1 

i 

Pow6r 

Mode 

Todey 

'TiiigeCOay 

Editing 

Saved 

1 

SwIlehOh 

OH 

On 

Yes 

Yes 
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RuM  I  UMTI 


SMKhOn 


Todiy  Targa^y  EdMng  Savad 


QatTbdayS 


S  QaiTodayC 


<*>ircn 


AccaaaCalandar 


AccataOttwr 


9  I  AccaaaOttMT 


10 

SpadfyOayS 

On 

11 

SpacMyOayS 

On 

12 

SpadlyOayC 

On 

13 

SapcilyOayC 

On 

14 

VI«mN«XI 

On 

15 

ViaafNaxt 

On 

16 

VlawNaxt 

On 

17 

ViawNaxt 

On 

18 

OverView 

On 

19 

Edit 

On 

20 

CornmM 

On 

21 

OeleteOne 

On 

22 

DelMoiehAppt 

On 

23 

DoOlher 

On 

TiMe  2.  PPS  spcciflcatkMi  of  a  schtdak  organizer 

By  following  the  mechanical  translation  steps  identified  in  Section  S.4.,  the  SMV  program 


of  the  schedule  organizer  can  be  easily  obtained  according  to  Table  2.  The  source  program  is 
iiK:luded  in  Appendix  I. 

6.2.  Category  of  Questions 

In  the  following  subsections,  each  explains  one  category  of  questions,  provides  u  template 
for  casting  the  questions  as  CTL  formulae,  and  gives  verihcution  examples  on  the  schedule 
oiganizer.  Note  that  in  the  template  description,  s-stmt  denotes  a  logic  formula  expressed  in 
terms  of  a  state  value  or  a  conjunction  of  state  values  (e.g.,  Power=of  f,  Today=Yes  &  Edit- 
ing=No);  e-stmt  denotes  a  logic  formula  expressed  in  terms  of  an  event  label  (e.g.,  even- 
taAccessSchedule,  event=Deleteone).  If  there  is  more  than  one  stmt  emerging  in  the 
template,  the  numeric  suffix  denotes  whether  the  stmt\  should  be  the  same  or  could  be  dif¬ 
ferent. 

6.2.1.  Rule  Set  Connectedness 

Question;  Given  initialization,  can  all  rules  somehow  be  enabled? 

We  assume  that  all  rules  are  put  forth  for  some  purpose.  If  some  rule  is  impossible  to  tire, 
there  is  potentially  a  problem  in  the  dialog  design.  The  designer  needs  to  either  revisit  the 
dialog  design  or  simply  eliminate  the  useless  rule.  In  the  following  template,  e-stmt 
expresses  the  event  associated  with  a  rule,  and  s-stmt  captures  the  pre-condition  of  that  rule. 

Template:  ef  {e-stmt  &  s-stmt)  for  each  rule 

Example:  EF(event=SwitchOn  &  Power=Off) 

EF(event=SwitchOf f  &  Power=On) 

EF (event =Get Todays  &  Power=On) 

EF ( event  =GetTodayC  &  Power  =On ) 

EF (event=AccessSchedule  &  Power=On) 

EF(event=AccessCalendar  &  Power=On) 

EF (event =AccessOther  &  Power=On) 

EF (event ^SpecifyOayS  &  Power=On  &  Mode=Schedule) 

EF (event=SpecifyDayC  &  Power=On  &  Mode=Calendar ) 

EF (event=ViewNext  &  Power=On  &  Mode=Schedule  &  TargetDay=Yes ) 
EF(event=VievrtJext  &  Power=On  &  Mode=Schedule  &  Today=No  & 

TargetDay =Yes ) 

EF (event = Vi ewNext  &  Power=On  &  Mode=Schedule  &  Today=Yes  & 

TargetDay=Yes ) 

EF (event “OverView  &  Power=On  &  Hode=Calendar ) 

EF( event “Edit  &  Power “On  &  Mode“Schedule) 

EF (event “Conanit  &  Power=On  &  Editing=Yes) 

EF (event“DeleteOne  t  Power=On  &  Mode=Schedule  &  Editing=No) 

EF (event“DelMonthAppt  &  Power=On  &  Mode=Calendar  &  Editing=No) 

EF (event “DoOther  &  Power=On  &  Mode=Other) 

The  above  formulae  verify  whether  all  rules  in  the  schedule  organizer  dialog  example  can 
eventually  be  enabled.  SMV  reports  that  all  are  true. 
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hJLL  Free  of  Deadlock 

Qiicstioa:  Given  initialization,  is  it  true  that  the  dialog  will  never  get  into  a  state  where  no 
user  events  can  be  taken? 

That  is,  we  want  to  avoid  the  situation  where  none  of  the  regular  user  events  are  enabled, 
and  the  only  event  that  a  user  can  take  is  the  special  “stuck  "  event.  Such  a  situation  would 
of  course  be  very  annoying  to  a  user. 

Template:  !EF  (event-stuck)  or  equivalently,  !EF(no_enabled) 

Example:  !EF(event=stuck) 

! EF ( no_enabl ed ) 

Either  of  the  above  formulae  is  sufficient  to  verify  this  property,  since  the  two  formulae  are 
equivalent  in  our  translated  CTL  model.  SMV  reports  both  true. 

6JU.  Free  of  Live  Deadlock 

Question:  From  any  state  of  a  given  state  set,  can  the  user  escape  from  that  state  set? 

In  the  template,  s-stmtl  expresses  the  state  set  to  escape  from. 

Template:  AG{s-stmtI  ->  ef{  \s-stmtJ) ) 

Example:  AG(Mode=Other  ->  EF(  !Mode=Other) ) 

AG (Mode*Schedule  ->  EF{ !Mode=Schedule) ) 

AG (Mode*Calendar  ->  EF < !Mode»Calendar) ) 

The  above  formulae  verify  if  a  user  can  always  escape  from  the  Schedule  mode,  Ccdendar 
mode,  and  Other  mode,  respectively.  SMV  reports  all  true. 

6^4.  Weak  Task  Completeness 

Question:  Can  a  user  find  some  way  to  accomplish  a  task  from  initialization?  Accomplish¬ 
ment  of  a  task  is  represented  in  terms  of  a  particular  state  that  could  be  reached  or  a  particu¬ 
lar  user  action  that  could  be  taken. 

In  the  template,  s-stmt  and  e-stmt  express  the  tasks  need  to  be  accomplished. 

Template:  SFis-stmt)  or  ef (e-stmt) 

Example:  EF(  Todays  Yes) 

EF(TargetDay=Yes  &  Edicing=yes  4  Saved=No) 

EF { event=OverView) 

EF(Mode=Calendar  4  Editing=Yes> 

The  first  formula  checks  if  the  system  can  reach  a  state  where  today  is  the  current  day.  The 
second  formula  checks  if  the  system  can  reach  a  state  where  a  user  can  specify  a  desired  day 
and  edit  an  appointment  while  the  appointment  is  not  yet  saved.  The  third  formula  checks  if 
a  user  can  overview  a  month’s  schedule.  The  fourth  formula  checks  if  a  user  can  edit  some- 


thing  while  in  the  Calendar  mode.  SMV  reports  that  the  first  three  formulae  are  true  but  the 
fourth  one  is  false.  It  is  obvious  that  the  last  one  does  not  hold  since  the  system  must  be  in 
tlw  Schedule  mode  before  a  user  can  edit  an  appointment. 

Strong  Task  Completeness 

Question:  Can  the  dialog  model  inevitably  lead  a  user  to  accomplish  an  important  task  from 
initialization?  Accomplishment  of  a  task  is  also  represented  in  terms  of  a  particular  state  that 
could  be  reached  or  a  particular  user  action  that  could  be  taken. 

This  property  is  valuable  for  a  novice  user.  The  dialog  inevitably  leads  the  user  to  try  some 
important  or  most  frequently  used  functions  without  the  user  searching  which  actions  to 
take.  On  the  other  hand,  we  might  want  a  negative  answer  to  this  question  if  we  want  to 
avoid  a  novice  user  unintentionally  performing  some  undesired  tasks  such  as  changing  the 
time  setting  of  a  watch  when  viewing  the  time  display.  In  the  template,  s-stmt  and  e-stmt 
express  the  tasks  need  to  be  accomplished. 

Template:  AF(.r-rrmr )  or  pjp  (e-stmt) 

Example:  AF(Today=Yes) 

AF ( TargetDay=Yes  &  Editing=Yes  &  Saved=No) 

AF {event=OverView) 

AF (Mode=Calendar  &  Editing=Yes) 

The  formulae  check  if  the  four  tasks  identified  in  the  previous  subsection  can  be  inevitably 
completed.  Only  the  first  one  is  true  because  initially  only  SwitchOn  action  is  enabled  and 
SwitchOn  leads  to  today  as  the  current  day. 

6.2.6.  State  Inevitability 

Question:  From  any  state  of  a  given  state  set,  will  the  dialog  model  absolutely  take  the  user 
to  a  critical  state? 

We  usually  want  to  make  sure  no  matter  how  the  user  navigates  through  the  system,  the  user 
can  absolutely  get  to  an  important  state  or  a  frequently  needed  state.  In  the  template,  s-stmt  1 
is  the  given  state  set,  and  s-stmt2  is  the  target  state  set. 

Template:  kg  (s-stmt I  ->  kf  (s-stmt2) ) 

Example:  AG(Mode=Other  ->  AF (TargetDay=Yes) ) 

AG(Mode=Other  ->  AF(Today=Yes) ) 

AG(Mode=Other  ->  AF (Mode=Schedule  &  Today=Yes) ) 

AG(Editing=Yes  &  Saved=No  ->  AF ( Saved=Yes ) ) 

The  above  four  formulae  should  be  self-explanatory.  SMV  reports  only  the  second  one  is 
true.  However,  it  is  highly  desired  that  the  fourth  formula  holds,  which  ensures  that  a  u.ser 
will  never  accidentally  lose  what  he  is  editing.  This  desired  property  would  hold  if  we 
change  the  rule  set  in  a  way  that  a  user  must  “commit”  the  edited  appointment  before  leav¬ 
ing  editing. 
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6JJ7.  Weak  Task  Connectechiess 

Question:  From  any  state  of  a  given  state  set,  no  matter  which  enabled  action  a  user  is  going 
to  take,  can  the  user  find  some  way  to  get  to  a  target  state  set? 

In  the  template,  s-stmtJ  is  the  given  state  set,  and  s-stmtl  is  the  target  state  set. 

Template:  PiOis-stmtl  ->  EF{s-stmt2) ) 

Example:  AG{Today=No  &  TargetDay=No  ->  EF  (Today=Yes  &  TargetDay=Yes )  ) 

AG (TargetDay=Yes  &  Editing=Yes  &  Saved=No  ->  EF(Saved=Yesn 
AG (Mode=Calendar  &  Editing=Yes  ->  EF (Mode=Schedule ) ) 
AG(Mode=Schedule  ->  EF {Mode=Calendar  &  Editing=Yes) ) 

The  first  formula  checks  whether  a  user  can  get  to  today  as  the  desired  day  if  currently  the 
system  is  not  at  today  and  is  not  at  a  user’s  desired  day.  The  second  formula  checks  whether 
a  user  can  save  an  edited  appointment  if  currently  the  system  is  at  a  desired  day,  a  user  is 
editing  appointment,  and  the  appointment  is  not  yet  saved.  The  first  two  formulae  are  verifi- 
ably  true.  Notice  that  the  third  formula  is  trivially  true  because  the  dialog  will  never  reach  a 
state  where  the  system  is  in  the  Calendar  mode  and  at  the  same  time  a  user  is  editing  an 
appointment.  Also  notice  that  the  fourth  formula  is  false  because  of  the  same  reason. 

It  is  important  to  notice  that  this  template  generally  poses  a  question  which  is  stronger  than 
needed.  Since  we  include  the  event  to  be  taken  as  part  of  the  state  information,  if  the  prop¬ 
erty  of  AG(s=sJ  ->  EF(s-s2))  holds,  it  not  only  guarantees  that  there  exists  some  way  to 
arrive  at  s2  from  si,  but  also  means  that  “whatever  enabled  action  a  user  is  going  to  take 
when  the  system  is  in  the  state  set  of  si,  there  exists  a  way  to  arrive  at  s2."  Alternatively,  we 
might  provide  a  template  as  follows: 

Template:  ef  {s-stmtl  &  ef  (s~stmt2) ) 

However,  this  template  poses  a  question  which  is  too  weak.  If  the  property  of  EF(s=sI  & 
EF(s=s2))  holds,  it  only  means  that  there  exists  a  particular  state,  say  t,  in  the  state  set  of  si 
(where  t  e  si),  and  from  t  there  exists  a  way  to  arrive  at  s2. 

There  is  one  way  to  express  exactly  the  question  we  want  to  ask,  as  illustrated  in  the  follow¬ 
ing  template.  This  template,  however,  requires  an  exhaustive  enumeration  of  all  possible 
events. 

Template:  ag(  (s-stmtl  &  e-stmt  I  ->  ef  {s-stmt2) )  ( 

( s-stmtl  &  e-stmt2  ->  ef  {s-stmt2) )  [ 

{ s-stmtl  &  e-stmtS  ->  ef  (s-stmt2) )  1 
...  for  each  event  in  the  event  set) 

We  choose  to  provide  a  stronger  template  because  it  subsumes  what  is  generally  asked  and 
does  not  need  to  explicitly  list  all  elements  in  the  event  set. 
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6.2.8.  Strong  'Kuk  Connectedness 

Question:  From  any  state  of  a  given  state  set,  no  matter  which  enabled  action  a  user  is  going 
to  take,  can  the  user  find  some  way  to  get  to  a  target  state  set  via  a  particular  user  action? 
This  particular  user  action  is  supposed  to  be  the  last  action. 

This  property  makes  sense  since  a  user  may  easily  remember  one  particular  user  action  to 
accomplish  a  desired  task.  In  the  template,  s-stmtl  is  the  given  state  set,  e-stmt  is  the  partic¬ 
ular  user  event,  and  s-stmt2  is  the  target  state  set.  Notice  that  the  template  also  poses  a  ques¬ 
tion  which  is  stronger  than  the  one  generally  asked  because  it  considers  whatever  enabled 
action  a  user  initially  is  going  to  take. 

Template:  ag  (s-stmtl  ->  zf  (e-stmt  &  AX.{s-stmt2) ) ) 

Example:  AG(Today=No  &  TargetDay=No 

->  EF (event =GetTodayS  &  AX{Today=Yes  &  TargetDay=Yes ) ) ) 
AG{Today=No  &  TargetDay=No 

->  EF (event = Spec if yDayC  &  AX(Today=Yes  &  TargetDay=Yes ) ) ) 

The  first  formula  checks  whether,  by  doing  GetTodayS,  a  user  can  get  to  today  as  the  desired 
day  if  currently  the  system  is  not  at  today  and  is  not  at  a  user’s  desired  day.  This  is  verifiably 
true.  The  second  formula  checks  whether  a  user  can  achieve  the  same  by  doing  SpecifyDciyC, 
and  this  is  false.  This  result  does  not  matte*'  since  we  intentionally  non-deterministically 
define  Today's  post-condition  to  be  either  Yes  or  No. 

6.2.9.  Rule  Reversibility 

Question:  Given  a  rule  which  is  going  to  fire,  is  it  possible  to  eventually  reverse  the  state 
back  to  the  original  situation  after  the  rule  fires? 

A  user  may  want  to  reverse  the  effect  of  a  rule  in  terms  of  getting  back  to  the  same  choice  of 
user  events.  In  the  template,  e-stmt  expresses  the  event  associated  with  a  rule,  and  s-stmtl 
captures  the  pre-condition  of  that  rule. 

Template:  ag (e-stmt  &  s-stmtl  ->  ex  ef( s-stmtl) ) 

Example:  AG(  event  =ViewNext  & 

Power=On  &  Mode=Schedule  &  Today=No  &  TargetDay=Yes 
->  EX  EF(Power=On  &  Mode=Schedule  &  Today=No  &  TargetDay=Yes ) ) 

The  above  example  verifies  this  property  for  rule  15  and  rule  16  as  they  have  the  same  pre¬ 
condition,  and  this  formula  verifiably  holds. 

6.2.10.  Undo  within  N  Steps 

Question:  From  any  state  of  a  given  state  set,  if  the  next  state  leads  the  system  out  of  the 
state  set,  can  a  user  go  back  to  the  given  state  set  within  N  steps? 

Template;  ACis-stmtJ  ->  ex(  \s-stmtl  ->  (EX.(s-stmtI)  |  ex  EX(s-stmtl)  |  ...  N  times) ) 
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Exampte:  AG(Editing=Yes  ->  EX( ! Editing=Yes  ->  EX(Editing=Yes) ) ) 
AG(Editing=Yes  ->  EX( ! Editing=Yes  ->  EX(Editing=Yes)  | 

EX  EX(Editing=Yes) ) ) 

The  first  formula  verifies  that  once  a  user  leaves  editing  he  can  go  back  to  edit  within  one 
step,  and  the  tool  reports  it  is  false.  The  second  formula  verifies  the  same  within  two  steps, 
and  the  tool  reports  it  is  true. 

It  is  critical  to  note  that  the  template  is  valid  only  for  state  variables  whose  post-conditions 
are  deterministically  decided.  Suppose  that  for  a  particular  action  the  variable  s  can  be  non- 
deterministically  assigned  as  either  si  or  s2  and  the  property  of  AG(s=sl  ->  EX(!s=sl  -> 
EX(s-sl)))  is  true.  This  does  not  guarantee  that  si  can  be  undone  within  one  step  because  s 
may  be  assigned  as  si  and  this  makes  !s-sl  ->  EX(s=sl)  vacuously  true  and  therefore 
EX(!s=sl  ->  EX(s=sl))  true.  However,  if  there  exists  a  case  in  which  si  cannot  be  undone 
within  one  step  when  s  is  assigned  as  s2,  then  the  verification  result  gives  a  fake  conclusion. 

6.2.11.  Accessibility 

Question:  From  any  reachable  state,  can  the  user  find  some  way  to  get  to  some  critical  state 
set  (such  as  the  help  system)? 

In  the  template,  s-stmt  expresses  the  critical  state  set. 

Template:  ag  £F{s-stmt) 

Example:  ag  EF{Today=Yes  &  TargetDay=Yes) 

To  use  a  schedule  organizer,  it  is  frequently  necessary  to  get  to  today  as  the  desired  day  at 
any  time.  The  example  verifies  this  property  and  the  result  is  true. 

6.2.12.  Accessibility  within  N  Steps 

Question:  From  any  reachable  state,  no  matter  which  enabled  ac.ion  a  user  is  going  to  take, 
can  the  user  find  some  way  to  get  to  some  critical  state  set  within  N  steps  (such  as  the  help 
system)? 

In  the  template,  s-smtl  expresses  the  critical  state  set.  Notice  that  since  we  include  event 
label  as  a  state  variable,  checking  accessibility  within  one  step  usually  ends  up  with  false¬ 
ness.  For  example,  a  simple  counterexample  against  the  property  of  AG{EX(state~s))  would 
be  a  state  different  from  s  with  some  user  event  e  (which  is  going  to  be  taken)  which  retains 
the  state.  This  kind  of  checking  makes  more  sense  if  the  property  is  asked  for  N  >  /. 

Template:  AG  (EX  (5-5rmry)  |  EXEyns-stmtl)  |  ...N  times) 

Example:  AG(EX(Today=Yes  &  TargetDay=Yes)  ) 

AG ( EX ( Today =Yes  &  TargetDay=Yes)  | 

EX  EX(Today=Yes  4  TargetDay=Yes ) ) 

The  first  formula  checks  if  today  can  be  designated  as  the  desired  day  within  one  step  and 
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the  result  is  false.  A  counterexample  is  when  the  system  is  at  the  state  of  Today^No  and  Tar- 
getDay—No,  and  event=AccessSchedule,  there  exists  no  next  state  in  which  Today=  Yes  and 
TargetDay=Yes,  since  the  action  of  AccessSchedule  will  not  change  the  variables  of  Today 
and  TargetDay.  The  second  formula  checks  if  Today=Yes  and  TargetDuy=Yes  can  be 
accessed  within  two  steps  from  anywhere  and  the  result  is  true  because  the  dialog  provides 
the  GetTodayS  and  GetTodayC  actions. 

6.2.13.  State  Avoidability 

Question:  From  a  given  state  set,  can  a  user  reach  a  target  state  set  without  entering  an 
undesired  state  set? 

The  reason  for  this  kind  of  checking  is  that  sometimes  it  is  annoying  to  inevitably  get  into  an 
undesired  state.  In  the  template,  s-stmtl  is  the  given  state  set,  s-stmt2  is  the  undesired  state 
set,  and  s-stmt3  is  the  target  state  set,  and  e-stmtl,  e-stmt2,...  etc.  are  the  events  that  the  user 
will  not  perform. 

Template:  KG(s~stmtl  &  \s-stmt2  &  \  e-stmt  I  &  \e-stmt2  Sc ...  as  necessary 
->  E[ !  (s-stmt2)  u  (s-stmtS)  ] ) 

Example:  AG(Mode=Schedule  & 

!Editing=Yes  & 

! event=Edit 

->  E [ ! Editing=Yes  U  Mode=Calendar] ) 

AG(Power=On  & 

!Today=Yes  & 

! event =GetTodayS  &  ! event =GetTodayC 
->  E[!Today=Yes  U  TargetDay=Yes] ) 

AG (Mode=Calendar  & 

!TargetDay=Yes  & 

! event =Spec if yDayC  &  ! event =Spec if yDayS  & 

! event =GetTodayS  &  ! event =GetTodayC 
->  E [ !TargetDay=Yes  U  Editing=Yes) ) 

All  three  formulae  hold.  The  first  formula  checks  that,  from  the  Schedule  mode,  a  user  can 
get  to  the  Calendar  mode  without  the  need  of  editing  an  appointment.  During  this  course, 
certainly  the  user  will  not  choose  to  edit  an  appointment  as  otherwise  it  is  the  user  who 
intentionally  edits  something.  The  second  formula  checks  that  from  any  state  when  the  power 
is  on,  a  user  can  specify  a  desired  day  without  having  today  as  the  current  day.  The  third 
formula  checks  that  from  the  Calendar  mode,  a  user  can  edit  an  appointment  without 
designating  a  specific  day. 

It  is  interesting  to  notice  that,  because  our  CTL  machine  includes  the  event  that  a  user  can 
take  as  part  of  the  state  information,  the  process  of  checking  this  property  may  require 
incrementally  filtering  out  the  events  which  a  user  will  not  select  to  perform.  For  example,  to 
check  the  first  case,  the  designer  might  initially  specify  something  like 

AG (Mode=Schedule  & 

!Editing=Yes  & 

->  E[ ! Editing=Yes  U  Mode=Calendar] ) 
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This  would  result  in  falseness  since  the  formula  did  not  eliminate  the  Edit  action.  By  looking 
through  the  counterexample,  the  designer  can  decide  whether  the  event  that  the 
counterexample  provides  makes  sense  when  a  user  wants  to  avoid  the  state  of  Editings  Yes. 
Then  the  designer  can  filter  out  the  Edit  event  that  a  user  will  not  perform.  However,  in  some 
cases  it  is  clumsy  to  filter  out  the  events  one  by  one.  For  example,  the  last  case  requires 
explicitly  filtering  out  four  user  events. 

6.2.14.  Event  Constraint 

Question;  Does  the  dialog  model  ensure/prohibit  a  particular  user  action  for  a  given  state 
set? 

In  the  template,  s-stmt  expresses  the  given  state  set,  and  e-stmt  denotes  the  user  event  which 
needs  to  be  assured/prohibited. 

Template:  AGis-stmt  ->  e-stmt)  or  ag (s-stmt  ->  \e-stmt) 

Example:  AG(Editing=Yes  ->  !  event=DeleteOne) 

If  a  user  can  delete  an  appointment  when  editing  an  appointment,  it  would  be  confusing  to 
the  user  since  which  appointment  will  be  deleted  is  not  clear.  The  example  checks  whether  a 
user  is  disallowed  to  perform  deletion  when  editing.  This  property  holds  for  the  dialog. 

6.2.15.  Feature  Assurance 

Question:  Does  the  dialog  model  assure  a  desired  feature  in  a  given  state  set? 

In  the  template,  s-stmt  I  expresses  the  given  state  set  and  s-stmt2  the  desired  feature. 
Template:  ag{  s-stmt  1  ->  s-stmt2) 

Example:  AG(Editing=No  ->  Saved=Yes) 

The  example  checks  if  there  is  no  appointment  lost  when  a  user  is  not  editing.  This  property 
is  false  for  this  dialog  since  when  a  user  is  editing,  there  are  lots  of  ways  to  leave  editing 
without  saving  the  edited  appointment  first.  This  suggests  a  way  to  modify  the  dialog  as 
Section  6.2.6.  does. 

6.3.  Summary  of  Insights 

Firstly,  in  our  attempt  of  providing  templates  for  frequently  asked  questions,  some  difficul¬ 
ties  arise  because  we  include  the  event  (that  a  user  can  take)  as  part  of  the  state  information 
in  our  translated  CTL  machine.  This  results  in  the  following  undesired  facts: 

•  The  templates  given  in  Section  6.2.7.  and  Section  6.2.8.  are  stronger  than  needed. 

•  The  template  given  in  Section  6.2.12.  generally  does  not  make  sense  if  the  ques¬ 
tion  is  asked  for  IV  s  /. 
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•  The  template  given  in  Section  6.2.13.  needs  to  explicitly  Alter  out  certain  events 
that  a  user  will  not  select  to  take. 

To  eliminate  this  problem,  one  possibility  is  to  use  the  approach  by  Atlee  and  Gannon  [9]. 
They  model  the  event-based  system  using  two  distinct  kinds  of  states;  an  EXIT  state  deter¬ 
mines  which  event  to  take,  a  -EXIT  state  captures  the  result  of  firing  an  event.  The  system 
runs  alternately  between  an  EXIT  state  and  a  -EXIT  state.  However,  their  translation  is 
based  on  a  different  kind  of  requirements  specification  called  SCR,  which  is  more  complex 
than  PPS.  At  this  point,  we  are  unable  to  say  whether  their  approach  can  resolve  our  difficul¬ 
ties  identified  above. 

Secondly,  we  allow  non-determinism  in  a  PPS  dialog  description  because  we  believe  it 
makes  a  PPS  description  more  expressive  when  the  dialog  design  is  conducted  at  a  higher 
level  (e.g.,  we  put  no  limit  on  the  number  of  appointments  for  each  day  in  the  scheduler 
organizer  example).  However,  non-determinism  inhibits  the  designer  from  using  the  tem¬ 
plate  given  in  Section  6.2.10.  This  leaves  a  trade-off  for  the  designer:  either  constructing  a 
deterministic  PPS  specification  (less  expressive)  and  being  able  to  check  the  undo  property, 
or  writing  a  non-deterministic  one  (more  expressive)  and  unable  to  check  the  undo  property. 

Thirdly,  to  question  the  accessibility  and  reversibility  properties,  the  designer  usually  wants 
to  know  directly  how  easy  it  is  to  access  a  critical  state  or  to  undo  an  effect.  However,  the 
templates  we  provide  can  only  check  whether  something  can  eventually  be  done,  or  some¬ 
thing  can  be  done  within  certain  steps.  It  would  be  helpful  if  the  tool  can  compute  the  maxi¬ 
mum  and  minimum  steps  needed  to  access  a  particular  state  or  to  undo  an  undesired  effect. 
The  new  advances  in  model  checking  show  there  are  algorithms  to  accomplish  this  and  have 
already  been  incorporated  in  the  tool  [10].  This  potentially  can  provide  the  ability  of  com¬ 
puting  the  “cost  functions”  for  reversibility  and  accessibility. 


7.  Animated  Feedback  for  Fix-up  and  Improvement 

If  SMV  tool  reports  that  a  CTL  formula  is  false,  it  will  try  to  give  a  counterexample  output 
in  a  log  file.  The  counterexample  includes  a  series  of  state  transitions  starting  from  an  initial 
state  which  violates  the  property  being  checked.  Note  that  in  the  printout  of  an  execution 
sequence  by  SMV,  only  the  values  of  variables  that  change  are  printed.  We  are  particularly 
interested  in  the  event  variable  since  its  change  suggests  the  sequence  of  user  actions  that 
explains  why  and  how  the  property  does  not  hold.  In  addition,  the  variable  of  pre,  (7  <  /  < 
N)  indicates  whether  rule  /  is  enabled. 

Currently  our  approach  of  feeding  the  counterexample  back  to  the  animation  tool  is  still 
primitive.  We  examine  the  values  of  event  variable  and  manually  perform  the  sequence  of 
user  events  in  the  Action  Simulator.  For  example,  the  counterexample  for  the  property  of 
AG(Editing=Yes  &  Saved=No  ->  AF(Saved=Yes))  is  listed  in  Appendix  II.  This  is  a  desired 
property  since  it  ensures  that  an  unsaved  appointment  needs  to  be  inevitably  saved  and  thus 
a  user  will  never  accidentally  lose  an  edited  appointment.  The  counterexample  suggests  a 
sequence  of  actions:  SwitchOn,  AccessSchedule,  Edit,  AccessSchedule,  Edit,  AccessSched- 
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ule,...  (repeat  Edit  and  AccessSchedule  forever).  From  the  experience  of  executing  this 
sequence  in  Action  Simulator,  the  problem  is  that  there  are  lots  of  actions  a  user  can  choose 
when  the  user  is  editing  something.  Only  the  Commit  action  will  actually  save  the  appoint¬ 
ment  while  the  user  may  accidentally  choose  one  of  the  other  enabled  actions  (such  as 
SwitchOjf,  AccessSchedule,  AccessCalendar,  AccessOther,  GetTodayS,  GetTodayC,...  etc.) 
without  saving  the  edited  appointment.  One  way  to  refine  this  situation  is  to  have  Edit¬ 
ing-No  being  a  pre-condition  of  all  actions  except  Edit  and  Commit,  and  therefore  a  user 
must  commit  the  appointment  before  leaving  editing. 

There  are  several  problems  of  this  primitive  approach.  First,  the  SMV  tool  will  not  give  an 
indication  in  the  case  where  it  cannot  generate  a  counterexample.  The  tool  simply  prims  out 
an  initial  state  and  nothing  else.  When  only  an  initial  state  is  printed  out,  we  need  to  figure 
out  whether  it  is  a  “real”  counterexample  or  it  implies  that  a  counterexample  cannot  be  pro¬ 
vided.  Second,  we  need  to  locate  at  which  point(s)  of  the  counterexample  the  property  being 
checked  is  violated.  This  means  that  we  must,  based  on  the  property  being  verified,  under¬ 
stand  the  “context”  of  scenario  given  by  the  counterexample  and  interpret  the  counterexam¬ 
ple  appropriately.  Third,  since  we  allow  multiple  rules  to  be  associated  with  the  same  event 
label  (as  we  want  to  allow  non-determinism),  we  cannot  decide  exactly  which  rule  to  fire  by 
only  examining  the  event  variable  in  the  counterexample.  We  also  need  to  examine  the  other 
state  variables,  especially  the  ones  which  are  non-deterministically  defined,  to  properly 
select  which  rule  to  fire.  At  this  point,  we  have  not  yet  resolved  these  issues  and  cannot  pro¬ 
vide  an  automated  process  for  animated  feedback. 


8.  Conclusion  and  Future  Work 

Our  work  demonstrates  that  it  is  possible  to  link  an  event-based  tabular  dialog  specification 
with  the  powerful  model  checking  technology,  whereby  a  PPS  dialog  can  be  modeled  as  a 
CTL  state-based  machine  and  analyzed  using  the  SMV  model  checker.  The  result  is  a 
method  whose  specification  interface  is  intuitive  and  whose  analysis  is  automatable.  The 
mechanical  translation  from  PPS  to  SMV  we  present  in  this  report  means  that  this  process 
can  be  automated.  We  also  provide  a  collection  of  CTL  templates  to  answer  certain  kinds  of 
frequently  asked  questions.  This  can  reduce  the  need  of  learning  deep  model  checking  tech¬ 
niques  for  average  programmers.  We  also  show  how  a  counterexample  of  a  property  can  be 
used  to  improve  the  dialog  design.  However,  there  are  many  directions  that  this  research  can 
be  carried  on. 

We  have  already  built  the  automatable  translation  process  from  PPS  to  SMV.  It  is  desired  to 
have  a  corresponding  automatable  process  to  tie  the  knot  from  SMV  back  to  PPS  through 
Action  Simulator  or  some  other  appropriate  simulation  tool.  This  can  give  more  sensible 
feedback  to  the  designer  via  visualization  and  therefore  provide  better  facilities  to  improve 
the  design.  Moreover,  the  collection  of  templates  presented  in  this  report  is  crude  and  simply 
a  start.  It  would  be  extremely  helpful  to  have  a  codification  of  templates  available  to  ordi¬ 
nary  designers.  The  goal  is  to  build  a  tool  to  automate  step  3  and  step  5  identified  in  Figure 
1,  and  incorporate  the  codification  into  it. 
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Some  difficulties  of  establishing  templates  resulted  from  the  fact  that  our  translated  CTL 
machine  involves  the  enabled  user  events  as  state  information.  Atlee  and  Gannon  used  a 
two-stage  transition  approach  to  model  a  different  form  of  event-driven  specifications  [9]. 
An  interesting  subject  is  to  investigate  if  their  approach  can  better  support  our  needs. 

Properties  concerning  accessibility  and  reversibility  generally  require  to  know  how  easy  a 
state  can  be  accessed  or  how  easy  an  effect  can  be  undone.  Campos,  Clarke,  et  al.  presented 
algorithms  to  calculate  the  minimum  and  maximum  lengths  over  paths  leading  from  a  set  of 
starting  states  to  a  set  of  final  states  [10].  We  believe  that  this  advance  can  readily  be 
adopted  by  our  approach  to  compute  the  cost  functions  of  many  properties. 

The  relationship  of  our  work  to  Statemate  system  [13]  needs  to  be  examined.  There  are  at 
least  two  interesting  topics  in  this  direction.  First,  it  would  be  useful  to  know  the  difference 
of  the  kinds  of  properties  analyzable  by  our  approach  and  Statemate.  Second,  our  tabular 
specification  grows  flat  as  we  add  rules.  However,  a  system  usually  has  different  aspects  of 
behavior  which  are  orthogonal  with  each  other,  and  the  designer  should  be  able  to  focus  on 
one  aspect  at  a  time.  The  statechart  [11][12],  the  foundation  of  Statemate,  provides  a  hierar¬ 
chical  way  to  specify  complex  state  transitions.  We  need  to  investigate  if  it  is  possible  to 
impose  some  kind  of  structure  on  our  tabular  specification. 
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MODULE  main 
VAR 
Power 
Mode 
Today 
TargetDay 
Editing 
Saved 
event 


Off,  On  ) ; 

Schedule,  Calendar,  Other  ) ; 

Yes,  No  ) 

Yes,  No  ) 

Yes,  No  ) 

Yes ,  No  ) 

SwitchOn,  SwitchOff,  GetTodayS,  GetTodayC,  AccessSchedule, 
AccessCalendar ,  AccessOther,  SpecifyOayS,  SpecifyDayC, 
ViewNext,  OverView,  Edit,  Commit,  DeleteOne,  DelMonthAppt , 
DoOther,  stuck  ); 


DEFINE 

prel 

=  Power=Off; 

pre2 

=  Power =Off; 

pre3 

=  Power =On; 

pre4 

•=  Power =On  ; 

pre5 

=  Power =On; 

pre6 

=  Power =On; 

pre7 

=  Power =On; 

pre8 

=  Power =On; 

pre9 

=  Power =On; 

prelO 

: =  Power=On 

& 

Mode=Schedule ; 

prell 

: =  Power=On 

& 

Mode=Schedule ; 

prel  2 

: =  Power=On 

& 

Mode=Calendar  ,- 

prel  3 

:=  Power=On 

& 

Mode=Calendar ; 

prel  4 

II 

1 

II 

§ 

& 

Hode=Schedule 

prelS 

: =  Power =On 

& 

Hode=Schedule 

prel  6 

; =  Power=On 

& 

Mode=Schedule 

i  TargetOay=Yes; 

&  Today=No  t>  TargetDay=Yes; 
&  Today=No  &  TargetDay=Yes ; 
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pr«1.7  :s  Powttr^On  k  Mo<l0>SchedUle  k  Today^Yes  k  Tar  get  Day = Yes ; 

prelS  :*  Power-On  k  HodasCalendar; 

pral9  :>  Power-On  k  ModezSchedule; 

pre20  :a  Power-On  k  Editingsyes: 

pre21  Power^iOn  k  Mode^Schedule  k  Edi.ting=No; 

pre22  Power-On  k  Mode=Calendar  k  Edlcing=No; 

pre23  :=  Power=On  &  Hode=Other; 

no_enabled  :=  !  (prel  |  pre2  |  pre3  |  pre4  |  preS  (  pre6  |  pre7  |  pre8  ( 

pre9  I  prelO  |  prell  |  prel2  |  prel3  |  prel4  |  prelS  |  prel6  | 
prel7  1  prelS  |  prel9  |  pre20  |  pre21  1  pre22  |  pre23); 
postl  :=  next ( Power ) =On  k  next (Mode) =Mode  k  next (Today ) =Yes  & 

next (TargetOay) =Yes  k  next (Editing) ^Editing  k  next (Saved) =Saved; 
post2  next ( Power ) =On  k  next (Mode) =Mode  &  next (Today ) =Yes  & 

next (TargetOay) =No  k  next (Editing) =Editing  k  next (Saved) = Saved ; 
post3  :=  next ( Power) =0£f  k  next (Mode) =Hode  k  next (Today) =Today  & 

next (TargetOay) =TargetDay  k  next (Editing) =No  k  next (Saved) =Saved; 
post4  :=  next (Power )= Power  &  next (Mode) = Schedule  &  next (Today) =Yes  k 
next (TargetDay) =Yes  k  next (Editing) =No  k  next (Saved) =Saved; 
posts  :=  next (Power) = Power  k  next (Mode) =Calendar  t  next (Today) = Yes  & 
next  (TargetDay)  =Yes  k  next  (Editing)  ^No  k  next  (Saved)  ^^Saved; 
posts  :=  next (Power) = Power  &  next (Mode) ^Schedule  k  next (Today ) =Today  & 

ii.^xt  (TargetDay)  =TargetDay  k  next  (Editing)  =No  &  next  (Saved)  ^Saved; 
post7  :=  next (Power) =Power  k  next (Mode) -Calendar  k  next (Today ) =Today  k 

next (TargetDay) =TargetDay  &  next (Editing) =No  k  next (Saved) =Saved; 
posts  :=  next (Power) = Power  &  next ( Mode ) =Other  fc  next (Today) = Yes  k 

next (TargetDay) =Yes  4  next (Editing) =No  4  next (Saved) =Saved; 
posts  :=  next (Power) = Power  4  next ( Mode ) =Other  4  next (Today )= Yes  4 

next (TargetDay) =No  4  next (Editing) =Mo  4  next (Saved) = Saved; 
postlO  :=  next (Power) = Power  4  next (Mode) =Made  4  next (Today) =Yes  4 

next (TargetDay) =Yes  4  next (Editing) =No  4  next (Saved) =Saved; 
postil  :=  next (Power) = Power  4  next (Mode) ^Mode  4  next (Today) =No  4 

next (TargetDay) =Yes  4  next ( Editing) =No  4  next (Saved) = Saved ; 
postl2  :=  next (Power) = Power  4  next (Mode) =Mode  4  next (Today) = Yes  4 

next (TargetDay) =Yes  4  next (Editing) =No  4  next (Saved) = Saved ; 
postl3  :=  next (Power) sPower  4  next (Mode) =Mode  4  next (Today) =No  4 

next (TargetDay) =Yes  4  next (Editing) =No  4  next (Saved) =Saved; 
postl4  ;=  next ( Power ) =Power  4  next (Mode) =Mode  4  next (Today ) =Today  4 

next (TargetDay) =TargetDay  4  next (Editing) =No  4  next (Saved) = Saved; 
postlS  ;=  next (Power) =Power  4  next (Mode) =Mode  4  next (Today ) =Yes  4 

next (TargetDay) =No  4  next (Editing) =No  4  next (Saved) =Saved; 
postl6  :=  next (Power) =Power  4  next (Mode) =Mode  4  next (Today ) =No  4 

next (TargetDay) =No  4  next (Editing) =No  4  next (Saved) =Saved; 
postl7  ;=  next (Power) =Power  4  next (Mode) =Mode  4  next (Today) =No  4 

next (TargetDay) =No  4  next (Editing) =No  4  next (Saved) = Saved; 
postlS  :=  next ( Power )=Power  4  next (Mode) =Mode  4  next (Today ) =Today  4 

next (TargetDay) ^TargetDay  4  next (Editing) ^Editing  4  next (Saved) = Saved ; 
postl9  :=  next (Power) =Power  4  next (Mode) =Mode  4  next (Today ) =Today  4 

next (TargetDay) ^TargetDay  4  next (Editing) =Yes  4  next (Saved) =No; 
post20  :=  next (Power) sPower  4  next (Mode) =Mode  4  next (Today) =Today  4 

next (TargetDay) =TargetDay  4  next (Editing) =No  4  next (Saved) =yes; 
post21  next (Power) =Power  4  next (Mode) =Hode  &  next (Today ) =Today  4 

next (TargetDay) sTargetDay  4  next (Editing) ^Editing  4  next (Saved) =Saved; 
post22  next (Power) sPotrar  4  next (Mode) =Mode  4  next (Today) =Today  4 

next (TargetDay) =TargetDay  4  next (Editing) =Editing  4  next (Saved) =Saved; 
post23  :=  next ( Power ) =Power  4  next (Mode) =Node  4  next (Today ) =Today  4 

next (TargetDay) ^TargetDay  4  next (Editing) ^Editing  4  next (Saved) =Saved; 
default  :=  next (Power) =Power  4  next (Mode) =Node  4  next (Today) =Today  4 

next (TargetDay) =TargetDay  4  next (Editing) =Editing  4  next (Saved) =Saved; 

INIT 

(Power-Off  4  Mode=Other  4  Editing=No  4  Saved=Yes)  4 
( (prel  4  eventsSwitchOn)  | 

(pre2  4  event-^SwitchCTn)  | 

(pre3  4  event sSwitchOff)  | 

(pre4  4  eventsGetTodayS)  | 


(pr«5  &  «v«neBG«tTodayC)  | 

(pr«6  k  •v«nt>Acc«aaSc)Mdule)  | 

(pra7  k  avant^AccaaaCalandar)  | 

(pra8  k  avantxAccaaaOchar)  | 

(pra9  k  evantxAcceaaOthar)  | 

(pralO  k  •vent=SpecifyDayS)  | 

(prall  k  evant=SpecifyOayS)  | 

(prel2  &  eventsSpecifyDayC)  | 

(prel3  k  event =Spec if yOayC)  | 

(prel4  &  event  =VievfNext)  | 

(prelS  k  event=Vie«rtlext)  | 

(prelS  k  eventsViewNext I  | 

(prel7  k  event^ViewNext)  | 

(prelS  k  event=OverView)  | 

(prel9  k  event=Edit)  { 

(pre20  k  event=Conuiiit)  | 

(pre21  k  event-OeleteOne)  | 

(pre22  k  event=DelMonthAppt)  | 

(pre23  k  event=OoOther)  { 

(no_enabled  k  event=stuck) ) 

TRANS 

( (event=SwitchOn  k  prel  k  postl)  { 
(event=SwitchOn  k  pre2  k  post2)  | 
(event=SwitchOf f  k  pre3  k  post3)  | 
(event=GetTodayS  k  pre4  &  post4)  | 

( event =GetTodayC  &  preS  &  posts )  | 
(event=AcceasSche<iule  &  pre6  k  post6)  | 
(event=AccessCalendar  k  pre7  k  post7)  | 
(event=AccessOther  k  preS  k  posts )  | 
(event=AccessOther  k  pre9  k  post9)  { 
(eventsSpecifyDayS  k  prelO  k  postlO)  | 

( event =SpecifyOayS  k  prell  k  postil)  ) 
(events Spec ifyOayC  &  prel2  &  postl2)  | 
(events Spec ifyDayC  k  prel3  k  postl3)  | 

( event sViewNext  &  prel4  &  postl4)  | 

( event sViewNext  &  prelS  &  postlS)  | 

( event sViewNext  Sc  prel6  Sc  postlS)  | 

( eventsViewNext  &  prel7  Sc  postl7)  | 
(eventsOverView  Sc  prelS  Sc  postlS)  | 
(eventsEdit  k  prel9  k  postlS)  | 

( event sConmit  Sc  pre20  Sc  post20)  | 
(eventsDeleteOne  k  pre21  k  post21)  { 
(eventsDelHonthAppt  k  pre22  k  post22)  | 

( event sDoOther  &  pre23  Sc  post23)  | 
(eventsstucic  &  no_enabled  k  default))  k 
((next (prel)  k  next (event) =SwitchOn)  | 
(next(pre2)  k  next (event) sSwitchOn)  { 
(next(pre3)  k  next (event) =SwitchOff)  | 
(next(pre4)  k  next (event) sGetTodayS)  | 

(next (preS)  k  next (event) sCetTodayC)  | 
(next(pre6)  &  next (event) sAccessSchedule)  | 
(next(pre7)  k  next (event) =AccessCalendar)  | 
(next (preS)  k  next ( event ) =AccessOther)  | 
(next(pre9)  k  next (event) sAccessOther)  | 
(next(prelO)  S^  next  (event)  sSpec if yDayS)  [ 
(next(prell)  k  next ( event ) =Spec if yDayS)  | 
(next(prel2)  k  next (event) sSpec if yOayC)  | 
(next(prel3)  k  next (event) =SpecifyOayC)  | 
(next(prel4)  k  next (event) sViewNext)  | 
(next(prelS)  k  next  ( event )  svieirtlext)  | 

(next (prelS)  &  next (event) =ViewNext)  | 
(next(prel7)  k  next (event) sViewNext)  | 

(next (prelS)  k  next (event) sOverView)  | 
(next(prel9)  k  next (event) sEdit)  | 
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(n«xt(pre20)  b  n«xc(«vant)>Coiinitl  | 
(n«xt(pr«21)  &  next(*v«nt)=D«leteOne)  1 
(n«xt(pr«22)  b  n«xt (event) =D«lMonthAppt)  1 
(next(pre23)  b  next (event) =DoOther)  | 

(next  (no_eneb led)  b  next  (event)  =atuc)c) ) 


Appendix  II 


--  specif ication  AG  (Editing  =  Yes  b  Saved  =  No  ->  AF  Sav.  .  is  false 
as  demonstrated  by  the  following  execution  se<iuence 
state  11.1: 
default  =  0 
post23  =  0 
post22  =  0 
post21  =  0 
post20  =  0 
postl9  =  0 
postlS  =  0 
postl7  =  0 
postie  =  0 
postlS  =  0 
postl4  =  0 
postl3  =  0 
postl2  -  0 
postil  =  0 
postlO  s  0 
posts  =  0 
posts  =  0 
post?  =  0 
posts  =  0 
posts  =  0 
post4  =  0 
post!  =  0 
post2  =  0 
postl  =  0 
no_enabled  =  0 
pre23  =  0 
pre22  =  0 
pre21  =  0 
pre20  =  0 
prel9  =  0 
prelS  =  0 
prel?  =  0 
prelS  =  0 
prelS  =  0 
prel4  =  0 
prel3  =  0 
prel2  =  0 
prell  =  0 
prelO  *  0 
pre9  =  0 
preS  =  0 
pre?  =  0 
preS  =  0 
preS  =  0 
pre4  =  0 
pre3  =  0 
pre2  =  1 
prel  =  1 
Po««er  =  Off 
Mode  =  Other 


Today  >  No 
TargotDay  ^  No 
Edicing  ^  No 
Savad  s  Yea 
event  >  SwitchOn 

state  11.2; 
pre23  =  1 
pre9  =  1 
pre8  =  1 
pre7  =  1 
pre6  s  1 
preS  =  1 
pre4  =  1 
pre3  =  1 
pre2  =  0 
prel  =  0 
Power  =  On 
Today  =  Yes 

event  =  AccessSchedule 

state  11.3; 
pre23  =  0 
pre21  =  1 
prel9  =  1 
prell  =  1 
prelO  =  1 
Mode  =  Schedule 
event  s  Edit 

--  loop  starts  here  -- 

state  11.4: 

pre2 1=0 

pre20  =  1 

Editing  s  Yes 

saved  =  No 

event  =  AccessSchedule 

state  11.5: 
pre21  =  1 
pre20  =  0 
Editing  =  No 
event  =  Edit 

state  11.6; 

pre21  =  0 

pre20  =  1 

Editing  =  Yes 

event  =  AccessSchedule 
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